From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 13 Jan 2005 15:21:21 +0000 Subject: Re: initramfs: udev, hotplug, klibc and modprobe Message-Id: <1105629682.9061.63.camel@localhost.localdomain> 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="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.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