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

[Lennart Poettering]

On Thu, 12.05.11 09:01, Scott James Remnant (scott at netsplit.com) wrote:

> 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.

We could optimize this in udev I guess. For example udev trigger could
just pass to udev ahead of time how many devices it needs to probe so it
could spawn a lot of processes right away, instead of slowly increasing
the number of workers. That said I don't know how udev currently handles
this. Maybe it already reacts fast enough for this. Kay knows if this
mgiht be a problem.

If this is really a problem we could probably also change the probing
order in udevadm trigger, and probe certain subsystems earlier than
others. (as has been suggested in another context already)

> 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.

I have my doubts that this would really cut it. I'd like to see hard
data on this before we optimize here.

> > 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?

udev continues to mark devices for ACL management. systemd will then
apply the ACLs based on seat/session info.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.