1 |
On Tue, 16 Feb 2016 20:14:03 +0100 |
2 |
Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
3 |
|
4 |
> Alexis Ballier schrieb: |
5 |
> > I also fail to see how udev using a new linux ipc would make it |
6 |
> > require systemd. Quoting Lennart: |
7 |
> > "You need the userspace code to set up the bus and its policy and |
8 |
> > handle activation. That's not a trivial task. For us, that's what |
9 |
> > sytemd does in PID 1. You'd need to come up with an alternative for |
10 |
> > that." |
11 |
> > |
12 |
> > If it's just that, it's not limited to udev, but anything using |
13 |
> > kdbus/bus1, and would mean openrc/${favorite init system} will have |
14 |
> > to do the same thing anyway. But again, almost 2 years is extremely |
15 |
> > old considering all the flux that has been around kbus. |
16 |
> |
17 |
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel |
18 |
> IPC system comes next. |
19 |
|
20 |
Well, as Lennart wrote it, kbus would have needed some initialisation. |
21 |
Just like we have a dbus init script, openrc would have a kdbus one. |
22 |
|
23 |
> But if upstream udev makes use of the systemd |
24 |
> userspace interface to the kernel IPC system, then OpenRC would have |
25 |
> to implement the same interface in order to have working udev. |
26 |
|
27 |
As I understand it, a kernel IPC doesn't need systemd to work. udev |
28 |
might use wrappers from libsystemd, or libbus1, just like we have |
29 |
programs using libv4l or libbluetooth currently. |
30 |
|
31 |
> Also given the close relationship between systemd and udev, there is |
32 |
> no guarantee that supporting other users of kdbus/bus1 will make udev |
33 |
> automagically work. As these two are released together, there is no |
34 |
> reason to have a stable, public API between them. |
35 |
|
36 |
Yes, which would mean systemd requires matching udev, not the other way |
37 |
around. I'm a bit clueless here: Do you have any pointers on the recent |
38 |
trends on this side ? |
39 |
|
40 |
Alexis. |