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

[Vojtech Pavlik <vojtech@suse.cz>]

On Wed, Feb 07, 2001 at 11:28:14AM -0800, David Brownell wrote:

> > 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:
> 
> Your steps 0..11 seemed plausible, though I'm not keen on those
> particular device names.  Reason:  I think that there needs to be a
> strong distinction between the USB "topology" names (which we
> don't have today except as a non-integrated kernel patch or in
> the Java USB library) and the names of the "logical devices" that
> drivers create using those USB devices.  And I think you weren't
> maintaining the distinction between those names.
> 
> 
> > 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).
> 
> I can see the hotplug agent (called by kernel or daemon) making
> intelligent policy decisions about the logical names to assign, but
> only if it's given good enough input.  Which will include "stable"
> names of various types, from lower levels (bus topology) or even
> from higher levels (network drivers may be able to determine
> stable MAC addresses).

I'm glad you like the scheme I described. I don't care about the naming
much, as long as it works.

> But in the name above, I think I see physical names admixed
> with logical ones ... so that's not a particular naming policy
> that I'd choose!

Depends on what you define as logical and physical. Yes, the "input bus"
is a purely virtual bus which has no physical representation. Still it
may behave like any other hotplugging bus, with input devices appearing
and disappearing, as lower-level modules register/unregister them.

The topology paths I've given above are just an example, and just one I
made up on the fly. However, I think they'd work:

/		is the host virtual bus
pci00.07.4 	is subdevice 4 of device 7 on PCI bus 0.
usb0.3 		is device in the fourth port (#3) on a hub attached
			to the first port on the USB card
input0		is the first input device on the input bus

And I probably made a mistake calling the last 'mousedev0', it should
have been

char13.32	which would be the mousedev device - a chardevice on
			major 13, minor 32.

> > 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 don't like "B" because it assumes predictive power in the hotplug
> daemon ... it has to predict/know how any driver will need names.
> That will lead quickly to chaos as the usermode code gets out
> of sync with the real behavior of that kernel driver.

In 'B' we wouldn't need to pass the whole 'topology path', instead
passing just the last part of the path would be enough.

> Also, keep in mind that statically linked modules need to fit into
> this scheme too.  Assigning "logical" names is in the "device init"
> phase of hotplugging, not the earlier "bind driver" (modprobe will
> not always help in binding).

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