Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@g.o> wrote:
>
> On Tue, 16 Feb 2016 23:41:33 +0100
> Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote:
>
>> 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."
>> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
>>
>> So it seems a bit more than only initialization is needed.
>
> You're missing the third option which is a sane option, and jump
> straight to pitchforks.
>
> As I see it, *if* this becomes a necessity, we're quite like are going
> to provide KDBUS parts of systemd the way we provide udev parts right
> now. After all, libsystemd-bus will be useful to more applications.
>
> Of course, someone may want to fork that into libebus just for the sake
> of renaming.
>
> And after all, as it has already been noted, there are people
> interested in maintaining non-systemd userspace for KDBUS. Which is
> kinda the obvious choice, unlike forking something.

kdbus is dead. It is fatally flawed and Greg is no longer trying to get it merged as he is not updating his branch for newer kernel versions. If I recall correctly, kdbus was also removed from Fedora and has no distribution backing it anymore.