[systemd-devel] [PATCH] Drop the udev firmware loader

[Lennart Poettering]

On Sun, 01.06.14 09:10, Samuli Suominen (ssuominen at gentoo.org) wrote:

> > Also note that at that point we intend to move udev onto kdbus as
> > transport, and get rid of the userspace-to-userspace netlink-based
> > tranport udev used so far. 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.
> >
> >
> 
> I've already set minimum kernel required to 2.6.39 in >= 213, and I'd
> be fine setting it even higher. Talking only of the udev bit here.  I
> don't like dropping support for old versions, but if that's what has
> to be done, I'll go with that.  Please, don't use this as an excuse to
> drop support for MinimalBuilds as described in wiki in some manner.
> As in, if it's still possible to use some kernel, like kernel with
> kdbus, and even if it requires an userspace library like
> 'libsystemd-something' to go with it, and still get a udev one way or
> another, that can run standalone, we are all good.

You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that.

> I'd really hate to be forced to fork (or carry huge patchset) unnecessarily
> (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what
> is provided to me by *you*, udev upstream)

Oh god. You know, if you come me like this as blame me that I would
"force" you to do something, then you just piss me off and make me
ignore you.

Anyway, as soon as kdbus is merged this i how we will maintain udev, you
have ample time to figure out some solution that works for you, but 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.

Also note that this will not be a change that is just internal between
udev and libudev. We expect that clients will soonishly just start doing
normal bus calls to the new udev, like they'd do them to any other
system service instead of using libudev.

Good luck,

Lennart

-- 
Lennart Poettering, Red Hat