| 1 |
On Mon, Nov 10, 2014 at 8:23 AM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
| 2 |
> On 11/10/2014 7:30 AM, Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> Well, there are no plans to make udev stop working without systemd as |
| 4 |
>> far as I can tell. HOWEVER, there ARE plans to require using kdbus to |
| 5 |
>> communicate with udev, and for that to work there needs to be a |
| 6 |
>> userspace initialization of kdbus/etc. |
| 7 |
> |
| 8 |
> So... you're saying I'm mis-reading this: |
| 9 |
|
| 10 |
Somewhat. |
| 11 |
|
| 12 |
> |
| 13 |
>> Unless the systemd-haters prepare another kdbus userspace until then |
| 14 |
>> this will effectively also mean that we will not support non-systemd |
| 15 |
>> systems with udev anymore starting at that point. Gentoo folks, this |
| 16 |
>> is your wakeup call. |
| 17 |
> |
| 18 |
> and that it doesn't mean that "udev will stop working without systemd", |
| 19 |
> or, as Lennart said, "... we will not support non-systemd systems with |
| 20 |
> udev anymore staryting at that point (when udev is moved onto kdbus as |
| 21 |
> transport)? |
| 22 |
|
| 23 |
The part that you're missing is the "Unless the systemd-haters [sic] |
| 24 |
prepare another kdbus userspace." |
| 25 |
|
| 26 |
Like many parts of the kernel, kdbus needs initialization from |
| 27 |
userspace. This is no different than what udev does in the first |
| 28 |
place - the kernel has device drivers, but SOMETHING has to populate |
| 29 |
/dev with device nodes if you want to use them. Now /dev has been |
| 30 |
around since the dawn of time, so we get our choice of 47 different |
| 31 |
ways of doing that. Kdbus hasn't been around for long at all, so |
| 32 |
nobody has really written any standalone processes for initializing |
| 33 |
it. |
| 34 |
|
| 35 |
As far as I can tell, udev will work just fine as long as something |
| 36 |
sets up kdbus. I'd have to study it a bit more to understand if there |
| 37 |
is some reason that this something has to be PID 1. |
| 38 |
|
| 39 |
I don't care for the attitude/etc and especially the treatment of |
| 40 |
Samuli (who seems to do his best to cooperate with everybody in this |
| 41 |
contentious area), but stepping back I can't really say that a project |
| 42 |
deciding to move to a new API based on a new IPC feature is all that |
| 43 |
controversial on its own. Normally when this sort of thing happens |
| 44 |
there are a bunch of projects built to support such a new kernel |
| 45 |
feature in userspace. |
| 46 |
|
| 47 |
I think the main reasons that we are where we are right now are: |
| 48 |
1. All the big distros are moving to systemd anyway, so they don't |
| 49 |
really have much of an itch to scratch here. |
| 50 |
2. Most folks not interested in systemd seem to generally not be |
| 51 |
interested in dbus at all. I think there is a lot of hope that this |
| 52 |
problem will just go away, and I suspect that if anything it will get |
| 53 |
a lot worse. |
| 54 |
3. Those who aren't using systemd to some extent are a bit split |
| 55 |
across udev, eudev, and busybox mdev. This does divide up the labor |
| 56 |
pool a bit and means interests aren't 100% aligned. |
| 57 |
|
| 58 |
The situation doesn't really see irreparable to me, but it does seem |
| 59 |
like there is something to be done. |
| 60 |
|
| 61 |
-- |
| 62 |
Rich |
Archives