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

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

> From: "David Woodhouse" <dwmw2@infradead.org>
> Sent: Monday, February 05, 2001 11:11 PM
>
> On Mon, 5 Feb 2001, David Brownell wrote:
> 
> > Serializing the order for event reports is a concern:  don't report
> > unplugs before you report the plug-in of that device, keep the device
> > identifiers stable.
> 
> 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. 

Originally they _were_ serialized, because the usermode helpers were
called synchronously by threads that only reported the events in
the appropriate sequence.  That is, serialization between subsystems
wasn't provided (shouldn't be, IMO), only within the subsystem
(say USB or PCI, which provided the thread).

My short version of "why did that change" was that the addition of
network hotplugging turned up some races (the network driver API
wasn't designed for hotplugging, unlike USB or PCI, and some locks
were held so usermode "ifconfig" could deadlock) and changing all
that was the expedient way out.  Andrew Morton can elaborate;
from test5 through test11, hotplugging was synchronous, without
any reported problems when used with USB.


>    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).

By itself, a queue won't solve the problems.  Entry #1:  new device
/proc/bus/usb/001/004 ... Entry #N: removes it ... Entry #M, new
device reusing the /proc/bus/usb/001/004 name.  Synchronization
of some kind is needed.  ("devfsd" dealt with some of these issues,
not that I use it; there may be ideas woth stealing from it.)

This subproblem might get simpler if the hotplug notifications can't
do more than identify a device type, and they can't access devices
(for stuff like serial numbers, alternative configurations, and other
such "extended type info") ... but that surely rules out some kinds of
necessary response to hotplug notifications.


> > The "boot time events" are all lost unless they can be inferred
> > from "usbdevfs" or (for PCI) "procfs".
> 
> Should be entirely feasible for a PCMCIA script to determine the devices 
> present during boot too, rather than queuing the actual events, then.

Modulo races between usermode code accessing devices using those
names, and the kernel invalidating and reusing them, yes.  "usbdevfs"
lets those issues be solved by keeping device nodes in that namespace
until the last open FD is gone, but there's a role for non-kernel code
to play too (talk to the FS safely, which can't quite be done with the
hotplug agent getting called asynchronously).

Not to overstate things:  typical usage scenarios today (only a few
devices, usage patterns still evolving) probably won't suffer too
much from these problems.  Yet.

- 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