Using Udev Without Systemd Is Going To Become Harder

[Teho]

Have you ever heard this: "If it isn't broken, DON'T TOUCH IT!"? Poettering is the one breaking things here, forcing people to fix them for him...

To fix what for him? You do understand that this change is only problematic to non-systemd user and I doubt he cares if non-systemd do nothing about it (like they usually don't)? You don't need to fix anything but if you want to have up-to-date udev you have do some work for once. Also Lennart isn't the one working on udev, Kay Sievers is.

[tomegun]

again, check out the protocols
netlink IS simpler and since it is not buffered it is, theoretically, lower overhead (and since it is not buffered it supports "mmaped" IPC, and there is no faster IPC then direct memory sharing)

firmware is just a bunch of bytes that the kernel sends to a device
how you get it to the kernel is another topic (in most cases the kernel gets it itself and that's why firmware is in /lib/firmware/, a path hardcoded in the kernel)
if you ask me there is nothing wrong with sending it over netlink
further more netlink is the standard to talk low level to device drivers
if i am wrong feel free to tell me why (and no "future" please, i like science more)

kdbus also does "mmaped" IPC, but without the limitations (multithreading is ok) and security problems (sealing) of netlink.

The firmware was never sent over netlink (only the request was), and it will never be sent over kdbus. Anyway, what you are talking about here is userspace-kernelspace communication, where there is no plans to introduce kdbus.

[gens]

kdbus also does "mmaped" IPC, but without the limitations (multithreading is ok) and security problems (sealing) of netlink.

The firmware was never sent over netlink (only the request was), and it will never be sent over kdbus. Anyway, what you are talking about here is userspace-kernelspace communication, where there is no plans to introduce kdbus.

about the firmware loading, now that you say it makes sense
shm kdbus doesn't thou, guess that is an extension
... still doesn't, guess i'l have to go back to reading the protocol (unless it changed much for kdbus)

so if netlink was made to replace ioctl in userspace - driver comunication then why use kdbus ?
i find netlink so-so simple and effective, guess that's just me

[Luke_Wolf]

Well, if you live in a perfect world, perhaps. But practically speaking, we don't. Modularity is a useful tool, but nothing more, and it's a hindrance as often as a help. All those little modules, all those separated concerns - they need to talk to each other, and that's a big piece of complexity right there. What happens if the requirements change, and one module needs extra information from another one? So you add that extra information to the interfaces? That's great, but then you find that someone else has provided a different implementation of those interfaces, and your changes have broken that implementation, and you don't have the ability to fix it. Now what?

See, don't get me wrong - modularity is a useful tool. But all that extra structure that goes with it - that's extra complexity, and you pay the price for having it.

If you're doing interfaces right that shouldn't happen, let's say that we've got an interface IFoo which has a method MemberA and we want to add a MemberB method to it, the correct response is not to directly add MemberB to IFoo but to create IBar which inherits IFoo, now if someone else comes up with a function of the same name MemberB but that has a completely different purpose they shouldn't use IBar but instead should Create IBaz which inherits from IFoo
so we have:
IFoo{
MemberA();
}
IBar:IFoo{
MemberA();
//some purpose
MemberB();
}
IBaz:IFoo{
MemberA();
//some completely different purpose
MemberB();
}
and then you cast to the expected behavior.

Ideally yes you wouldn't have that redundancy but an interface is a promise, and if they're doing incompatible things they're not the same interface.

[tomegun]

about the firmware loading, now that you say it makes sense
shm kdbus doesn't thou, guess that is an extension
... still doesn't, guess i'l have to go back to reading the protocol (unless it changed much for kdbus)

You want to look up "memfd". They are used when the data being transfered is bigger than a certain size (otherwise doing a copy is faster).

so if netlink was made to replace ioctl in userspace - driver comunication then why use kdbus ?

They are used for different things. kdbus is userspace to userspace, netlink is userspace to kernelspace. It is possible to use netlink for userspace to userspace, but it is not really nice (which is what udev is currently doing, and why we want to move that to kdbus).

i find netlink so-so simple and effective, guess that's just me

Yeah, it is very simple, but probably too simple in some respects. It is also not very efficient, at least not for rtnetlink (which is what I have worked with), as there is a global lock on the kernel side which means that the interface is essentially synchronous. That would not happen with kdbus (had the kernel been ported to use that for userspace-kernelspace communication, which of course it will not be).

[bkor]

Read this: http://lkml.iu.edu/hypermail/linux/k...4.0/01331.html . From this, you can infer that Kay *WAS* writting (alongside Greg) KDBus, and it seems to be the case: https://github.com/gregkh/kdbus/graphs/contributors .

Nope, Kay is not involved with the kernel code of kdbus. What Linus is referring to is that Kay removed something from udev, which caused a problem for the kernel. https://lwn.net/Articles/518945/. There's also a nice writeup of that.

[curaga]

If you didn't see this coming 1-2 years ago already, you are blind.

[gens]

You want to look up "memfd". They are used when the data being transfered is bigger than a certain size (otherwise doing a copy is faster).



They are used for different things. kdbus is userspace to userspace, netlink is userspace to kernelspace. It is possible to use netlink for userspace to userspace, but it is not really nice (which is what udev is currently doing, and why we want to move that to kdbus).



Yeah, it is very simple, but probably too simple in some respects. It is also not very efficient, at least not for rtnetlink (which is what I have worked with), as there is a global lock on the kernel side which means that the interface is essentially synchronous. That would not happen with kdbus (had the kernel been ported to use that for userspace-kernelspace communication, which of course it will not be).

memfd looks good
from what i see it's shm fd with toggleable owner, will check more when i get time

so kdbus won't be used to tell the kernel anything ?
its just for userspace coordination ?

netlink is a RAW/DGRAM based protocol
so how i see it, it can't be slower then an OO based protocol unless parsing on one side takes too long

can't say why would interacting with the routing tables be any faster using a buffered protocol instead of a synchronous one, netlink like a normal socket can send gigabytes per sec
unless the kernel side is poll based instead of event based, but even then
can you dump a bunch of commands at once, and if you can you could over a netlink multipart msg
too much idk here

[Vim_User]

To fix what for him? You do understand that this change is only problematic to non-systemd user and I doubt he cares if non-systemd do nothing about it (like they usually don't)? You don't need to fix anything but if you want to have up-to-date udev you have do some work for once. Also Lennart isn't the one working on udev, Kay Sievers is.

Indeed, it is Sievers that is working on udev. The same Sievers that said this:

The udev built from the systemd source tree will stay compatible with
non-systemd init systems for a long time. This change is mostly a
detail of the build scheme, rather than a change of direction or
interfaces. Accordingly, the libudev API is untouched by these build
infrastructure changes. For us, compatibility is key.

http://lwn.net/Articles/490413/
Apparently, a long time is for him a little more than two years, and apparently compatibility is not key anymore.

Seriously, a sentence from Poettering like "Gentoo folks, this is your wakeup call." in reality comes down to: "The Gentoo people are actually the only ones of the non-systemd distros that have the manpower to handle this change in a proactive way, all other non-systemd distros better bow to us or keep using outdated udev forever. Now that Debian and Ubuntu have decided to change to our side we can show our real intentions and start with the small distros that can't handle the changes due to lack of manpower. Resistance is futile!"

Don't get me wrong, I actually like systemd and its concepts, but it is its developers attitudes and actions like this that prevent me from using it.

[tomegun]

memfd looks good
from what i see it's shm fd with toggleable owner, will check more when i get time

See: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/

so kdbus won't be used to tell the kernel anything ?
its just for userspace coordination ?

Correct. As all of kdbus will be isolated in a kernel module, and there is not even plans of a dbus parser in the kernel yet, there will be no way to use kdbus for talking with the kernel (unless someone does a lot of work to make it happen of course, but I don't know about anyone who is seriously interested in that).

netlink is a RAW/DGRAM based protocol
so how i see it, it can't be slower then an OO based protocol unless parsing on one side takes too long
can't say why would interacting with the routing tables be any faster using a buffered protocol instead of a synchronous one, netlink like a normal socket can send gigabytes per sec
unless the kernel side is poll based instead of event based, but even then
can you dump a bunch of commands at once, and if you can you could over a netlink multipart msg
too much idk here

The bandwith is not a problem, the latency is (or rather, kdbus is much better than netlink from a latency POV, but both are probably good enough for most uses).

The way rtnetlink works is that your sendmsg() call will only return after the message has been fully processed (i.e., not only parsed, but the kernel will have finished changing your mac addresses or configuring your routing table before sendmsg() returns). If you only ever want to send one synchronous message, that is fine, but if you (as I do) want to send lots of unrelated asynchronous messages from a single-threaded application, it sort of sucks.