[systemd-devel] systemd inquiry

Lennart Poettering lennart at poettering.net
Sun Apr 22 03:54:29 PDT 2012


On Fri, 13.04.12 13:37, Mark Hounschell (markh at compro.net) wrote:

> 
> On 04/12/2012 08:25 AM, Mark Hounschell wrote:
> >On 04/11/2012 05:12 PM, Kay Sievers wrote:
> >>On Wed, Apr 11, 2012 at 22:44, Mark Hounschell<markh at compro.net> wrote:
> >>
> >>>Same thing. About 20 seconds after reaching the target, the device
> >>>entries
> >>>show up.
> >>
> >>Does that block or return immediately?
> >>rmmod<driver>;
> >>modprobe<driver>; time udevadm settle
> >>
> >>Your driver creates the stuff async?
> >
> >After booting up to graphical login:
> >
> >rmmod dgdm
> >modprobe dgdm ; time udevadm settle
> >
> >real 0m0.107s
> >user 0m0.000s
> >sys 0m0.000s
> >
> >modprobe blocks until the process has completed.
> >
> >
> >It appears, by watching the boot screen, when using sysvinit the boot
> >process pauses at a certain point until this has completed. It doesn't
> >stop as soon as it starts, but it does pause nun the less. Using systemd
> >it does appear to.
> >
> 
> Correction: Using systemd it does NOT appear to.

On a systemd system that lacks udev-settle in the boot path we do not
wait for any module to finish initialization at boot. This makes things
fast and clean but will not work if code that initializes later is not
capable of dealing with hardware being added at runtime.

If you enabled udev-settle we will delay boot for a certain amount of
time until all drivers that have been queued to load are finished (or a
timeout elapses). This is only necessary if your sw is incapable of
properly dealing with hw that shows up dynamically.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list