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