Re: initramfs: udev, hotplug, klibc and modprobe

["Alexander E. Patrakov" <patrakov@ums.usu.ru>]

J?rg Billeter wrote:

> On Mit, 2005-01-12 at 10:07 +0500, Alexander E. Patrakov wrote:
>> Kay Sievers 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".
>> 
>> See also my old alternative implementation:
>> 
>> http://bugs.linuxfromscratch.org/show_bug.cgi?id†8
>>
http://archive.linuxfromscratch.org/mail-archives/lfs-hackers/2004-July/001729.html
> 
> I've looked at it at that time, too, but there seem to exist some
> drawbacks:
> 
> - It doesn't support loading modules in initramfs and it seems that this
>   couldn't be added easily as udevd holds back some events until the
>   child process of previous events finished which never happens with
>   the sleeping hotplug processes.

It's still possible to extend my initramfs with a script that preloads a
predefined list of modules (like "modules" script in LFS 6.0). But it seems
that you are talking about something different - namely, loading modules
corresponding to devices found, like the original Hotplug package does.
This also seems possible to implement - just call the equivalent of the
original hotplug script before sleeping.

> - It doesn't work with run-init which moves the /root mount to /. With
>   your initramfs, the whole system will be run in chroot in a way that
>   a root user can escape it and get back to the initramfs tmpfs which
>   could be not that desirable.

Known problem. However, with run_init one cannot have guaranteed delivery of
hotplug events to the late userspace, just because a timeslice exists when
everything in initramfs has been erased, but move-mount hasn't yet
happened.

The situation might (I say "might", because I haven't investigated this
seriously) be better if run-init, instead of doing what it does now (erase
everything and then mount --bind and run init), forked itself. The parent
should create a new namespace (in order for /root/dev/null to remain a
valid path for already-spawned sleeping-hotplug processes), mount --bind,
signal the child, and execute the real init. The child, upon reception of
the signal, should do the cleanup.

Of course the waiting wrappers should also be modified to change the
namespace and redo the mount --bind, and also they should use a version of
the shell that doesn't rely upon "[" being a separate program (busybox has
such option; maybe it's even better to rewrite them in C).

I will investigate this further (and maybe come up with a revised initramfs
image) if you tell me to do so.

> - Some 100 processes test for /root/dev/null every second and will
>   be sent in possibly a random order to udevd at once (probably not
>   a major performance problem but we should consider it)

You won't believe me, but it _is_ a major performance problem if one uses a
dynamic translator like qemu in order to test this initramfs safely (exec
is very expensive since it requires the whole round of code translation).

As to your question concerning the event numbering that starts at 5 in your
case: you do miss some events. They start at 0. Probably this old kernel
patch is relevant: http://lkml.org/lkml/diff/2004/7/13/74/1 (I know that
there was a second patch shortly thereafter, that limits concurrency of
usermode helpers, but I can't find it now).

-- 
Alexander E. Patrakov
(don't CC: me, I read linux-hotplug-devel via gmane)



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