On Tue, 16 Feb 2016 23:41:33 +0100 Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> 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.
> >> Also given the close relationship between systemd and udev, there is
> >> no guarantee that supporting other users of kdbus/bus1 will make udev
> >> automagically work. As these two are released together, there is no
> >> reason to have a stable, public API between them.
> >
> > Yes, which would mean systemd requires matching udev, not the other way
> > around. I'm a bit clueless here: Do you have any pointers on the recent
> > trends on this side ?
>
> I have only upstream's statements from 2014. They talk about a kdbus
> userspace that systemd will provide to udev, which will be necessary for udev
> to function.
> If and when upstream comes forward with statements about whether udev will
> only use public and stable API, these concerns could be either dispelled or
> confirmed.
And here you have my statement, from today:
I declare that eudev will be discontinued. You should either move to
systemd, to alternative device manager or fork it. This is your last
call, Gentoo users!
Now please copy it to slashdot, reddit or whatever cool kids use these
days, and make sure to request at least half of existing eudev users
switch to something else because of the above statement.
Does it matter that I haven't contributed a single line to eudev code?
eudev upstream is Gentoo, and I'm a Gentoo developer. So I'm part of
upstream. Even if I don't touch eudev, I'm part of the upstream.
In fact, I think I even have commit access there!
If Lennart's single statement from 2014 is a reason to use eudev
instead of systemd-udevd, my statement from today is a more important
reason not to use eudev.
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpQTNn24wD65.pgp
Description: OpenPGP digital signature
