Re: initramfs: udev, hotplug, klibc and modprobe

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

On Wed, 2005-01-12 at 09:24 +0100, Jürg Billeter wrote: 
> On Mit, 2005-01-12 at 03:37 +0100, Kay Sievers wrote:
> > On Sun, 2005-01-09 at 23:25 +0100, Juerg Billeter wrote:
> > >               * [3] Patch to add udevinitd and udevinitsend. These are
> > >                 modified versions of udevd and udevsend acting as a
> > >                 "caching daemon". They save events received during early
> > >                 userspace and resend them to late userspace udevd when
> > >                 ready. This enables late userspace to process all events
> > >                 (for example to load modules not included in initramfs)
> > >                 without using coldplugging and thelike. (udevinitsend
> > >                 gets called via hotplug.d)
> > 
> > Nice idea. In a recent discussion, the question came up about a possible
> > combination of udevstart and coldplugging. It may be possible to
> > synthesize all the events from the information in sysfs? What do you
> > think about that in relation to your udevd "event queue".
> 
> If really all events could be synthesized including the order/seqnum and
> one sets udevd's event queue on hold (to avoid race conditions between
> newly generated events and not yet "read" events) this probably works
> well. As there is no point in time a process can determine when there
> are no further incoming hotplug events, so it knows it is safe to start
> reconstruction / replay, there may still be race conditions, not sure.
> 
> My solution may be easier to implement / use when regarding possible
> race conditions but it possibly has drawbacks, too, I don't know.

On Wed, 2005-01-12 at 10:42 +0100, Harald Hoyer wrote:
I really would like to see the hotplay replay since September :) 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id\x133841#c6

Ok, sounds reasonable to reply the events as a replacement to faking the
hotplug events for coldplugging and running udevstart.

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

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