[systemd-devel] device units rely on udev rules?
Scott James Remnant
scott at netsplit.com
Thu May 12 09:01:04 PDT 2011
On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering
<lennart at poettering.net>wrote:
> > 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.
>
> It isn't "dead fast" enough.
The problem is that when you run udevadm trigger, it doesn't immediately
spawn 700 processes to handle the events. So you end up with situations
where input devices aren't available to X because the system is too busy
probing for filesystems, or loading sound card drivers.
And we really *can* mount file systems before their block devices have been
probed (they show up as soon as the driver's loaded). Actually the probing
code is exactly the kind of code I would want to delay; filesystems can be
mounted by GPT ids which doesn't require the expensive block device probing.
To my mind, we would want the filesystem mounted as soon as the kernel event
arrives, whether or not udevd is running and whether or not udevadm trigger
has been run.
> udev isn't just about symlinks. It's about perms and primarily about
> meta data, and a lot of other stuff too.
>
> perms are increasingly irrelevant due to ACLs, which your plans are moving
to systemd, no?
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110512/ff5b15d0/attachment-0001.htm>
More information about the systemd-devel
mailing list