[systemd-devel] device units rely on udev rules?

[Lennart Poettering]

On Mon, 09.05.11 11:53, Scott James Remnant (scott at netsplit.com) wrote:

> Another question I wasn't able to find an answer to in the documentation
> I've read so far.
> 
> The use of device units seems to very much rely on udevd running on the
> system, and not only that, udev rules having been parsed for the device and
> a systemd tag "set" in the udevdb. udev obviously starts after systemd, and
> systemd starts after the kernel.

Correct.

> This means there are a large number of devices already known to the kernel
> at the point that systemd starts, especially if you build the drivers into
> the kernel for those devices. It's possible to get going straight away with
> those devices. But relying on udevd tagging them means you end up waiting
> around for udevd to start, and worse! since udevd doesn't apply rules to
> existing devices on startup, you have to wait around for "udevadm trigger"
> to be run.

That's actually dead fast, and systemd picks up those devices as they
show up. The trigger can hence finish after we already preceeded
booting. In fact, with the new netlink actviation in newest udev and
systemd we can start the trigger at the same time as udev itself.

We cannot really mount file systems before their block devices have
shown up and have been probed, and we exactly wait for that, and no
longer. To do fsck/mount we need udev to have run for that device,
there's no realistic way around that.

> Given that devtmpfs means the device nodes are already available, and
> systemd will be merging the ACL handling from CK/udev into itself, why does
> systemd rely on udev coldplugging in this way? All that's left for udevd to
> do at this point is "device groups" (which should go really away on any
> modern distro) and symlinks.

Well, we do not really "rely" on this. Only a small subset of devices is
exposed in systemd. Block devices, network devices, ttys, sound cards
and a few others. All of these have in common that they are not
particularly useful before they have been probed.

The device nodes in devtmpfs that the kernel passes to us can be used
without dep config in systemd. However, it's probably a good idea to
limit use to the static devices with this, and only those. (with other
words: it's probably a bad idea to use /dev/sdc7 before it has been
probed, but using /dev/null is completely fine, and it wouldn't show up
in systemd anyway).

> There are probably many systems out there (hi!) that care so little about
> symlinks that they're happy for udevd to be started non-critically in the
> boot, and consider the "udevadm trigger" run a necessity that's probably the
> last thing to run.

Again, the emphasis is on parallelization: we want to run everything in
parallel, no artificial ordering in userspace.

udev isn't just about symlinks. It's about perms and primarily about
meta data, and a lot of other stuff too.
 
> What are the long term plans here? Do you envision this staying the way it
> is?

I am sure Kay can provide you with a bit of interesting data that shows
you that udev git + systemd git are so quick enumerating devices that we
have a lot of other stuff that needs more optimization than udev right
now.

That all said we actually want to optimize udev further, and reduce the
number of rules we have to process. But that's more Kay's turf, so ping
him if you have questions.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.