From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Date: Fri, 14 Jan 2005 10:27:12 +0000 Subject: Re: initramfs: udev, hotplug, klibc and modprobe Message-Id: <41E79E80.4010009@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 Fri, 2005-01-14 at 10:29 +0100, Hannes Reinecke wrote: > >>Kay Sievers wrote: >> >>>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 > > > If udevd already executes events before we get the initrams events > flushed in, we execute them not in the right order. Is this ok? > Shouldn't we just queue _all_ events until we got the initramfs ones? > > It's a bit tricky as we don't know on startup whether we'll get any initramfs events. If the user doesn't use udevinitd (or it fails or whatever) we'll be waiting forever. >>- 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. > > > Seems possible at least, to collect all events from the very beginning > on and replay them from real userspace without the need for coldplug or > udevstart. Sounds nice! We can even load-limit from udevd here. :) > Well, not quite, as udevsend will still be started from the kernel. But yes, load-limiting is a definite should-have. >>>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. > > > But we need to collect the events here with initudevd now. initudevd can > execute udev just like the real udevd does today, but keep the queue for > a later flush into the real udevd. > Yeah, sure. We'll have to do the queueing bit anyway. (Currently it's done in script-logic, not nice). 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