Alexis Ballier schrieb:
If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have
to do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.

OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
IPC system comes next.

Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.

But if upstream udev makes use of the systemd
userspace interface to the kernel IPC system, then OpenRC would have
to implement the same interface in order to have working udev.

As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.

In a follow-up, upstream wrote about how you should only run udev together with systemd, and if you don't want to do that (spelling as in original):

"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."

So it seems a bit more than only initialization is needed.

Also given the close relationship between systemd and udev, there is
no guarantee that supporting other users of kdbus/bus1 will make udev
automagically work. As these two are released together, there is no
reason to have a stable, public API between them.

Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?

I have only upstream's statements from 2014. They talk about a kdbus userspace that systemd will provide to udev, which will be necessary for udev to function. If and when upstream comes forward with statements about whether udev will only use public and stable API, these concerns could be either dispelled or confirmed.

Best regards,
Chí-Thanh Christopher Nguyễn

Reply via email to