Re: initramfs: udev, hotplug, klibc and modprobe

[Hannes Reinecke <hare@suse.de>]

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.

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

>>>I think initramfs should use the hotplug multiplexer and call the normal
>>>udev binary directly to create the nodes along with initudevd to queue
>>>the events.
>>>
>>
>>Ah well. The old problem.
>>In doing this you have to make sure to copy the _entire_ hotplug 
>>subsystem plus all called scripts and programs to initramfs.
>>Plus any configuration file used by any of those.
>>And you have to make sure that any change in those configuration file is 
>>being reflected to the initramfs, too.
>>
>>Still looking for proper ways of solving this. In the meantime, I opted 
>>for using a minimal hotplug version in initramfs: just set 
>>/proc/sys/kernel/hotplug to 'udev' to have all device nodes created and 
>>load all required modules by hand.
> 
> 
> But we need to collect the events here with initudevd now. initudevd can
> execute udev just like the real udevd does today, but keep the queue for
> a later flush into the real udevd.
>  
Yeah, sure.
We'll have to do the queueing bit anyway.
(Currently it's done in script-logic, not nice).

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


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