From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 14 Jan 2005 10:36:42 +0000 Subject: Re: initramfs: udev, hotplug, klibc and modprobe Message-Id: <1105699003.7556.94.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="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, 2005-01-14 at 11:27 +0100, Hannes Reinecke wrote: > 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. Can't we read the state from /proc/sys/kernel/hotplug which is still set to something different as /sbin/hotplug? > >>- 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. This will not really harm, I expect. udevsend exits very fast if it can send the event and if it can't send it is sleeping and not running. This is unlikely to cause problems. The hundreds of shells in "R" are the problem, right? 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