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

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

> > > > When I thought about this last year, my conclusion was that it SHOULD
> > > > be OK to have multiple event orderings so long as all were correctly
> > > > serialized with respect to essential criteria.  Just as if they were
> > >
> > > Essentially I believe you right. But which criteria ?
> >
> > "add" finishes before "remove" starts; the names of
> > devices are stable while those agents execute.
> > Minimal.
> 
> These are not enough. You must ensure that "remove" has finished before you
> start anything that reuses the device node.

I was assuming something that I suspect we should be considering
as a goal (an "architectural" one?): names passed by hotplug agents
must be stable.

Right now, PCI meets that requirement (PCI_SLOT).
USB does not, networking does not.

Before 2.4.0 went "final", USB changed its address assignment
so its names (busnum/devnum) were less unstable:  devnum is
assigned round-robin.  There's a patch I put together a while back
to give USB devices stable names, but it's not integrated.

I'll have to think more about Vojtech's comments.  I think I will
likely want the kernel to guarantee some stable name (is that a
place where devfs could really help?) and let all the mappings
to "virtual" names (like "eth0") be managed separately.


> You see, changing the order of events 2 and 3 is wrong.
> You'd have the wrong interfaces in printcap.  

Couldn't matter if the agent were passing the right stable names
though, right? 


> The amount of locking needed to be provided by shell scripts worries me.

Compiled code (C, Java, etc) accessing kernel configuration APIs can
kick in at any time it's really needed, don't worry about that one!


> > That means fixing some subsystem behaviors (using stable names for
> > network interfaces, as one example).  Architecturally, there is no sense
> > to letting two subsystems interfere with each other.
> 
> Then you'd need to have a stable name provided to the hotplug script.

Yes ...


> This is difficult, for several reasons.
> a) You need devfs (which is not PC)

"devfsd" is not PC for me, but I'm less clear why a "/devfs" wouldn't be fine.
Anyone care to start a separate thread on such topics?


> b) You know that name only after the driver is loaded. (You don't even know 
> the number of names, multifunction devices and bridges)

Device drivers can be viewed as adapters between namespaces:
loading a device driver may cause entries in other namespaces.

USB device "/proc/bus/usb/002/031" may be network interface "usb0".
The lower level name (USB) is known before "usbnet" is loaded,
but "usb0" isn't known till afterwards ... but then, USB hotplugging
sees the USB name, and network hotplugging is what sees "usb0".


> c) You'd need to call after drivers have bound to interfaces.

USB hotplug is called after the kernel gives drivers a chance to
bind to interfaces.

For network devices, hotplug is called after the driver created
and registered/named a new interface.


> d) There might be devices which have difficulties providing a stable name.

Then let them deal with it.  If the busses provide stable names, then we
can federate them in some namespace that can be used by layers above
the  busses.  "pci-02:7.3" can be a PCI device, and any driver that has
a hard time turning one stable name into another likely has other problems!


> These are conflicting requirements. In fact you'd need _two_ scripts. One to 
> load the driver, a second to configure the device the driver has bound to.

You mean like the difference between /etc/hotplug/*.agent (load driver FOO)
and /etc/hotplug/*/FOO (configure each new device)?  :-)

- 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