From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 06 Feb 2001 19:22:53 +0000 Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > From: "Jeff Garzik" > Andrew Morton wrote: > > David Woodhouse wrote: > > > > > > Er... we can wait for arbitrary lengths of time in execve(). So events > > > aren't serialised anyway, and cannot be if you report them by running a > > > userspace helper like this. You'd have to have a queue which is read by a > > > single userspace process (which could perhaps be spawned when the queue > > > becomes non-empty). > > > > I don't really understand why the /sbin/hotplug callout exists > > at all. If instead the kernel were to spit the event strings > > out of some FIFO device (character special or whatever) then > > hotplugd can perform all its actions nice and serially. One reason was to get rid of the added system costs of creating such a FIFO, creating a "hotplugd", then operating both of them (tying down system resources). After all, the kernel already has parsed event data in hand, and it's always going to be cheaper to allocate the hotplug agent resources for short periods than to keep them allocated at all times (order of 100 KBytes). The first implementation was a way to get _away_ from yet another user mode daemon, and its costs. The tradeoff was some simple kernel code (less than 512 bytes) against some complex kernel code to create/manage such a FIFO, and even more code to decode the FIFO data and call the same user mode agent the kernel could call directly. > > Plus we can buffer all the "insertion events" which occur > > from boot-time scanning so they're available when hotplugd > > starts up. > > I had been thinking the same thing. I think Linus originally said "do > it with /sbin/hotplug" and that's the way it went. I don't recall Linus doing more than acknowledging that such boot-time solutions were proven ("kudzu" on RedHat) and could easily just call the same /sbin/hotplug "subroutine" used when hotplugging. He did come up with the name "/sbin/hotplug" as a generic name that all kernel subsystems (not just USB :-) could use to deliver hotplug notifications ... with specific reference to 2.4 supporting USB, PCI, and network hotplugging. > My suggestion would be a ring buffer that includes a jiffy (or other) > timestamp before each event. That way it would be trivial for a > hotplugd to replay whatever events it missed... Didn't "devfsd" rely on such a thing? But it only knows about device files, not /proc/bus/* or network interfaces. Not relying on "devfs" was another requirement for the original hotplug work, but maybe that can be rethought for the 2.5 series. - Dave _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel