Re: initramfs: udev, hotplug, klibc and modprobe

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

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?

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

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

Yeah, sounds reasonable to have two version and replace the initudevd
process.

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