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

Kay Sievers kay.sievers at vrfy.org
Mon May 9 13:23:53 PDT 2011


On Mon, May 9, 2011 at 22:08, Lennart Poettering <lennart at poettering.net> wrote:
> On Mon, 09.05.11 22:02, Lennart Poettering (lennart at poettering.net) wrote:
>
>> > It's still in the 10 second range on a 600MHz cortex-a8 machine
>> > booting from an SD card. I need to dig out my 400MHz arm920t to see
>> > how long it takes there. So having udev-less operation in systemd
>> > would be nice, even if it's only used on 'embedded'
>>
>> Have you checked what precisely takes so long? My guess is that some
>> driver has a slow sysfs uevent trigger callback, and that might be
>> fixable in the driver. You might want to use strace with timestamps to
>> figure out why udev trigger might be so slow.
>
> Also note that only very few devices are exposed and depended on by
> systemd. In an embedded env you might be able to simple trigger those
> explicitly first, and then trigger the rest afterwards. That way you
> don't have to wait 10s, and the triggering will be dispatched in the bg,
> but you still get the flexibility that udev can handle hotplugged
> devices.
>
> Kay, opinions?

Guess that should work fine. I guess we could short-cut some stuff too
if it helps for custom setups, so systemd would look if the device is
already there, instead of wait for the tag to show up. But we would
need to find out if that really helps.

Real numbers of the most recent udev on such systems would help, so we
get an idea what we are dealing with.

Things like:
  time (udevadm trigger; udevadm settle)
would be good to know too. If that looks like something to fix, the output of:
  udevadm monitor
during the trigger command above will be useful too.

Kay


More information about the systemd-devel mailing list