Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell <david-b@pacbell.net>]

> From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> 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