| 1 |
Alexis Ballier schrieb: |
| 2 |
>>> If it's just that, it's not limited to udev, but anything using |
| 3 |
>>> kdbus/bus1, and would mean openrc/${favorite init system} will have |
| 4 |
>>> to do the same thing anyway. But again, almost 2 years is extremely |
| 5 |
>>> old considering all the flux that has been around kbus. |
| 6 |
>> |
| 7 |
>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel |
| 8 |
>> IPC system comes next. |
| 9 |
> |
| 10 |
> Well, as Lennart wrote it, kbus would have needed some initialisation. |
| 11 |
> Just like we have a dbus init script, openrc would have a kdbus one. |
| 12 |
> |
| 13 |
>> But if upstream udev makes use of the systemd |
| 14 |
>> userspace interface to the kernel IPC system, then OpenRC would have |
| 15 |
>> to implement the same interface in order to have working udev. |
| 16 |
> |
| 17 |
> As I understand it, a kernel IPC doesn't need systemd to work. udev |
| 18 |
> might use wrappers from libsystemd, or libbus1, just like we have |
| 19 |
> programs using libv4l or libbluetooth currently. |
| 20 |
|
| 21 |
In a follow-up, upstream wrote about how you should only run udev together |
| 22 |
with systemd, and if you don't want to do that (spelling as in original): |
| 23 |
|
| 24 |
"we will not support the udev-on-netlink case anymore. I see three options: |
| 25 |
a) fork things, b) live with systemd, c) if hate systemd that much, but |
| 26 |
love udev so much, then implement an alternative userspace for kdbus to |
| 27 |
do initialiuzation/policy/activation." |
| 28 |
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html |
| 29 |
|
| 30 |
So it seems a bit more than only initialization is needed. |
| 31 |
|
| 32 |
>> Also given the close relationship between systemd and udev, there is |
| 33 |
>> no guarantee that supporting other users of kdbus/bus1 will make udev |
| 34 |
>> automagically work. As these two are released together, there is no |
| 35 |
>> reason to have a stable, public API between them. |
| 36 |
> |
| 37 |
> Yes, which would mean systemd requires matching udev, not the other way |
| 38 |
> around. I'm a bit clueless here: Do you have any pointers on the recent |
| 39 |
> trends on this side ? |
| 40 |
|
| 41 |
I have only upstream's statements from 2014. They talk about a kdbus |
| 42 |
userspace that systemd will provide to udev, which will be necessary for udev |
| 43 |
to function. |
| 44 |
If and when upstream comes forward with statements about whether udev will |
| 45 |
only use public and stable API, these concerns could be either dispelled or |
| 46 |
confirmed. |
| 47 |
|
| 48 |
|
| 49 |
Best regards, |
| 50 |
Chí-Thanh Christopher Nguyễn |
Archives