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

[Alexis Ballier]

On Wed, 17 Feb 2016 13:58:51 +0100
Michał Górny <mgorny@g.o> wrote:

> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao <ryao@g.o> wrote:
>
> > > 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.
>
> Then... why are we even discussing this?
>

because s/kdbus/bus1/