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

[Vojtech Pavlik <vojtech@suse.cz>]

On Tue, Feb 06, 2001 at 06:11:07PM -0800, Miles Lane wrote:
> Andrew Morton wrote:
> 
> [...]
> 
> 
> > - I'm only talking about netdevices.  What happens with other
> >   types of device if the discovery order is randomised?  I
> >   dunno.
> 
> It appears that we currently only have representation of
> USB, PCI, PCMCIA and Network driver/bus developers in this
> discussion.  Is that as it should be?  It seems to me that
> the topic of device detection and configuration is quite
> important to get right for all hotpluggable busses.
> Should we be extending invitations to others?

Well, in my opinion we should also consider non-hotpluggable busses,
because even there it would make sense to use the same module loading
mechanism. It's more flexible than the current modules.conf way.

> It's clear that there are major usability problems that 
> arise from the lack of a MAC address equivalent for all 
> hardware devices.  

Many devices do have serial numbers, that's OK. Other devices do at
least have bus topology placement, ie. slot number on PCI, hub port on
USB, etc.

If the devices can't be identified by a unique number, then bus topology
is the only way how to describe which device is which, and thus is the
right one.

> As David Brownell mentioned, the typical usage pattern
> (at least for USB) seems to be that just a few devices
> are connected and usually not more than one device of
> a given type.  The confusion sets in when there are
> multiple USB mice, keyboards, videocams, etc.  If XFree86
> ever gets support for multi-headed consoles with support
> for dedicated mice and keyboards per console, getting the
> mapping from physical device to logical device (for example,
> /dev/input/mouse[1-4]) to stay consistent would be really
> helpful. I believe that this feature is actively being
> developed for XFree86, BTW.

Yes, it is. And yes, we need this. And bus topology (head #1 uses port
#1 on the USB card, head #2 uses port #2, etc.) is the way how to find
out which mouse is which.

I imagine it this way:

0) PCI layer finds a new device, registers it, calls the hotplug daemon
   passing the PCI IDs/class/prog-if and topology (/pci00.07.4)
1) Hotplug daemon checks the class/prog-if and loads usb-ohci module. 
2) usb-ohci module senses a new device, registers it w/ USB layer.
3) USB layer calls hotplug daemon, telling it the USB IDs/descriptors
   and bus topology position (/pci00.07.4/usb0).
4) Hoptlug module sees it's a hub and thus it's handled by a built-in
   USB hub driver.
5) The hub driver enables the ports on the hub, usb-ohci sees a new
   device, registers it w/ USB layer.
6) USB layer calls hotplug daemon, telling it the USB IDs/descriptors
   and bus topology position (/pci00.07.4/usb0/usb3).
7) Hotplug daemon checks the descriptors and decides it's a HID device
   and loads hid module.
8) The hid module registers a new device on the Input virtual bus.
9) Input layer calls hotplug daemon, telling it the Input IDs/bitmaps
   and bus topology position (/pci00.07.4/usb0.3/input0).
10) Hotplug daemon checks the bitmaps and decides it's a mouse and loads
   mousedev.o and evdev.o.
11) Mousedev.o registers a new chardevice minor, so does evdev.o.

I'm not completely sure where to fit the device naming in, I'm thinking
about two variants:

A) After step 11, Hotplug daemon is called by the
   char/block/scsi/net-device layer and the hotplug daemon decides
   about the minor number/name (based on IDs and topology path -
   /pci00.07.4/usb0.3/input0/mousedev0).

B) At every time the hotplug daemon is loading a module, it
   passes a name/number it wishes the new device that caused the load
   to be registered under. Example: Loading hid.o, register as 'input4'.

I think A is simpler and easier to do. It also will be fairly easy to
configure.

B gives complete control of device numbering, even for devices on
virtual busses. In the B case, only the last part of the topology would
need to be passed.  What do you think?

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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