On Mon, 09.05.11 11:53, Scott James Remnant (sc...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
