Re: initramfs: udev, hotplug, klibc and modprobe

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

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

How do we handle the events traveling in before we flush the queue to
the real udevd? Timeout?

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

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

> BTW: It should probably be possible to have different versions of udev
> in the initramfs archive in the kernel and in userspace, at the moment I
> suppose this wouldn't work with my setup as udevd seems to check the
> version number in the messages.

Yes, we once had a binary struct with the values which made the magic
necessary. Now we have only a serialized environment. If we end with two
versions of udevd we may just think about removing the magic check.

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