From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Date: Fri, 14 Jan 2005 09:29:16 +0000 Subject: Re: initramfs: udev, hotplug, klibc and modprobe Message-Id: <41E790EC.8020104@suse.de> 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 Kay Sievers wrote: > 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. :) > Oh, for sure. > How do we handle the events traveling in before we flush the queue to > the real udevd? Timeout? > No, we should do it with a staged approach: - Fire up udevd - send USR1 to udevinitd - udevinitd sends magic "Hey, this is udevsend talking to you" message to udevd - udevd stops executing events in response to that magic message - set /proc/sys/kernel/hotplug to udevsend - udevinitd sends events to udevd - any events sent by the 'real' udevsend will be queued - once udevinitd has sent all events to udevd, it sends a magic "I'm done with" message to udevd - udevd starts processing events. This way, we won't lose events plus all events will be executed in-order. > >>> 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. > Ah well. The old problem. In doing this you have to make sure to copy the _entire_ hotplug subsystem plus all called scripts and programs to initramfs. Plus any configuration file used by any of those. And you have to make sure that any change in those configuration file is being reflected to the initramfs, too. Still looking for proper ways of solving this. In the meantime, I opted for using a minimal hotplug version in initramfs: just set /proc/sys/kernel/hotplug to 'udev' to have all device nodes created and load all required modules by hand. > >>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? > That will be quite hard, as udevd in initramfs is started as a child of (Hmm, child of what indeed. One should check.). When doing the chroot() thing to the real rootfs the new namespace is only available to all children of init(), which the udevd in initramfs is certainly not. So the udevd would have to know where the rootfs is mounted and do a chroot() itself. Can't say I like this, as the mount point of the rootfs is not really defined and can be just anything. So having two distinct processes, one for initramfs and another one for the real thing is IMHO a better idea. Cheers, Hannes -- Dr. Hannes Reinecke hare@suse.de SuSE Linux AG S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de ------------------------------------------------------- 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