Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Richard Yao <ryao@g.o>
Cc: gentoo-dev@l.g.o, "Chí-Thanh Christopher Nguyễn" <chithanh@g.o>
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
Date: Wed, 17 Feb 2016 12:59:10
Message-Id: 20160217135851.68b7c554.mgorny@gentoo.org
In Reply to: Re: [gentoo-dev] Changing order of default virtual/udev provider by Richard Yao
1 On Wed, 17 Feb 2016 07:53:22 -0500
2 Richard Yao <ryao@g.o> wrote:
3
4 > > On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@g.o> wrote:
5 > >
6 > > On Tue, 16 Feb 2016 23:41:33 +0100
7 > > Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote:
8 > >
9 > >> Alexis Ballier schrieb:
10 > >>>>> If it's just that, it's not limited to udev, but anything using
11 > >>>>> kdbus/bus1, and would mean openrc/${favorite init system} will have
12 > >>>>> to do the same thing anyway. But again, almost 2 years is extremely
13 > >>>>> old considering all the flux that has been around kbus.
14 > >>>>
15 > >>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
16 > >>>> IPC system comes next.
17 > >>>
18 > >>> Well, as Lennart wrote it, kbus would have needed some initialisation.
19 > >>> Just like we have a dbus init script, openrc would have a kdbus one.
20 > >>>
21 > >>>> But if upstream udev makes use of the systemd
22 > >>>> userspace interface to the kernel IPC system, then OpenRC would have
23 > >>>> to implement the same interface in order to have working udev.
24 > >>>
25 > >>> As I understand it, a kernel IPC doesn't need systemd to work. udev
26 > >>> might use wrappers from libsystemd, or libbus1, just like we have
27 > >>> programs using libv4l or libbluetooth currently.
28 > >>
29 > >> In a follow-up, upstream wrote about how you should only run udev together
30 > >> with systemd, and if you don't want to do that (spelling as in original):
31 > >>
32 > >> "we will not support the udev-on-netlink case anymore. I see three options:
33 > >> a) fork things, b) live with systemd, c) if hate systemd that much, but
34 > >> love udev so much, then implement an alternative userspace for kdbus to
35 > >> do initialiuzation/policy/activation."
36 > >> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
37 > >>
38 > >> So it seems a bit more than only initialization is needed.
39 > >
40 > > You're missing the third option which is a sane option, and jump
41 > > straight to pitchforks.
42 > >
43 > > As I see it, *if* this becomes a necessity, we're quite like are going
44 > > to provide KDBUS parts of systemd the way we provide udev parts right
45 > > now. After all, libsystemd-bus will be useful to more applications.
46 > >
47 > > Of course, someone may want to fork that into libebus just for the sake
48 > > of renaming.
49 > >
50 > > And after all, as it has already been noted, there are people
51 > > interested in maintaining non-systemd userspace for KDBUS. Which is
52 > > kinda the obvious choice, unlike forking something.
53 >
54 > 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.
55
56 Then... why are we even discussing this?
57
58 --
59 Best regards,
60 Michał Górny
61 <http://dev.gentoo.org/~mgorny/>

Replies