From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alexander E. Patrakov" Date: Wed, 12 Jan 2005 09:59:10 +0000 Subject: Re: initramfs: udev, hotplug, klibc and modprobe Message-Id: List-Id: References: <1105307950.9630.49.camel@juerg-p4.bitron.ch> In-Reply-To: <1105307950.9630.49.camel@juerg-p4.bitron.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org J?rg Billeter wrote: > On Mit, 2005-01-12 at 10:07 +0500, Alexander E. Patrakov wrote: >> Kay Sievers wrote: >>=20 >> >> * [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) >> >=20 >> > 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". >>=20 >> See also my old alternative implementation: >>=20 >> http://bugs.linuxfromscratch.org/show_bug.cgi?id=868 >> http://archive.linuxfromscratch.org/mail-archives/lfs-hackers/2004-July/001= 729.html >=20 > I've looked at it at that time, too, but there seem to exist some > drawbacks: >=20 > - 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). --=20 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