Re: initramfs: udev, hotplug, klibc and modprobe

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, 2005-01-14 at 11:27 +0100, Hannes Reinecke wrote:
> Kay Sievers wrote:
> > On Fri, 2005-01-14 at 10:29 +0100, Hannes Reinecke wrote:
> > 
> >>Kay Sievers wrote:
> >>
> >>>How do we handle the events traveling in before we flush the queue to
> >>>the real udevd? Timeout?
> >>>
> >>
> >>No, we should do it with a staged approach:
> >>
> >>- Fire up udevd
> >>- send USR1 to udevinitd
> >>- udevinitd sends magic "Hey, this is udevsend talking to you" message
> >>   to udevd
> >>- udevd stops executing events in response to that magic message
> > 
> > 
> > If udevd already executes events before we get the initrams events
> > flushed in, we execute them not in the right order. Is this ok? 
> > Shouldn't we just queue _all_ events until we got the initramfs ones?
> > 
> It's a bit tricky as we don't know on startup whether we'll get any 
> initramfs events. If the user doesn't use udevinitd (or it fails or 
> whatever) we'll be waiting forever.

Can't we read the state from /proc/sys/kernel/hotplug which is still set
to something different as /sbin/hotplug?

> >>- set /proc/sys/kernel/hotplug to udevsend
> >>- udevinitd sends events to udevd
> >>- any events sent by the 'real' udevsend will be queued
> >>- once udevinitd has sent all events to udevd, it sends a magic
> >>   "I'm done with" message to udevd
> >>- udevd starts processing events.
> >>
> >>This way, we won't lose events plus all events will be executed in-order.
> > 
> > 
> > Seems possible at least, to collect all events from the very beginning
> > on and replay them from real userspace without the need for coldplug or
> > udevstart. Sounds nice! We can even load-limit from udevd here. :)
> > 
> Well, not quite, as udevsend will still be started from the kernel. But 
> yes, load-limiting is a definite should-have.

This will not really harm, I expect. udevsend exits very fast if it can
send the event and if it can't send it is sleeping and not running. This
is unlikely to cause problems. The hundreds of shells in "R" are the
problem, right?

Thanks,
Kay



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel