Re: initramfs: udev, hotplug, klibc and modprobe

[Hannes Reinecke <hare@suse.de>]

Kay Sievers wrote:
> On Thu, 2005-01-13 at 15:34 +0100, Juerg Billeter wrote:
> 
>>Kay Sievers wrote:
>>
>>> How does the transition from udevinitd to the real udevd look like on
>>> your box, Jürg? How are "real" events handled, traveling in during the
>>> transition?
>>
>>/proc/sys/kernel/hotplug gets set to /sbin/udevinitsend before entering
>>"real" userspace. This binary exists in both, initramfs and userspace
>>and acts almost like udevsend but sends the messages to udevinitd. So
>>messages sent during initializing real userspace will be sent directly
>>to udevinitd.
>>As soon as real userspace is ready, it kills the initramfs' udevd,
>>sets /proc/sys/kernel/hotplug to /sbin/udevsend and sends USR1 signal to
>>udevinitd which flushes the queue by sending the messages to the "real"
>>udevd.
> 
> 
> Ok, but how do we handle possible unfinished processes that want to send
> to the initudevd socket while we are killing the initudevd. I'm pretty
> sure that people find a way to create s setup with hundreds of processes
> still waiting. :)
> 
Oh, for sure.

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

> 
>>> Maybe udevd should be started from initramfs and never be replaced by a
>>> different one? We may just add a knob to the "real" udevd to hold the
>>> event execution back until userspace asks to flush the queue and udevd
>>> switches over to the current behavior.
>>
>>Yes, this looks sane but you need to keep in mind that the early hotplug
>>events need to be handled twice, once in early userspace (to load
>>modules required for mounting rootfs) and once in real userspace. So
>>udevd can't just hold the event execution back, it has to execute and
>>keep a separate queue.
> 
> 
> 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.

> 
>>A problem coming to my mind right now is that udevd doesn't know
>>anything about the overmount of the rootfs and AFAIK it can't access the
>>new/real rootfs without chroot/chdir at the right moment (between
>>mounting the new rootfs to /root and before mount move /root to /) or am
>>I mistaken here?
> 
> 
> Don't know. :) If needed we can do this along with the transition from
> "queue only" to "normal" behavior, right?
> 
That will be quite hard, as udevd in initramfs is started as a child of 
(Hmm, child of what indeed. One should check.). When doing the chroot() 
thing to the real rootfs the new namespace is only available to all 
children of init(), which the udevd in initramfs is certainly not.
So the udevd would have to know where the rootfs is mounted and do a 
chroot() itself.
Can't say I like this, as the mount point of the rootfs is not really 
defined and can be just anything.
So having two distinct processes, one for initramfs and another one for 
the real thing is IMHO a better idea.

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