Re: IDs (was Re: Hotplugging for the input subsystem)

[Vojtech Pavlik <vojtech@suse.cz>]

On Sat, Sep 29, 2001 at 03:15:36AM +0200, Tim Jansen wrote:

> > Small note: function number is more a location than an identifier,
> > various VIA chipset revisions with the same ID have different assignment
> > of functions, and each function has its own vendor and model ids.
> 
> My device id is not used to identify a certain kind (class) of devices, like 
> for example the Plug&Play IDs in Windows. It is used to find a device 
> instance that currently is or has been connected to the system. So if the 
> function changes this is a sign that it's a different device and the id 
> should be different.

Correct. But this doesn't mean that function number (the x in
pci00.00.x) isn't a location. Look:

You can have two devices with identical PCI ids and identical
functions in the system (example: two SB Live! cards):

	
	pci00.01.0 - 1102:0002
	pci00.01.1 - 1102:7002
	pci00.02.0 - 1102:0002
	pci00.02.1 - 1102:7002

Assuming the function numvber is a part of the device id and not the
location, this would create two pairs of identical unique IDs as per
your approach. This isn't a problem per se, but doesn't help anything.
It also means that there are two pairs of different devices with the
same physical location. This is imho not good.

On the other hand, if you add the function number to the location, you
still get identical ids, and on PCI you usually don't get serial numbers
anyway, but at least each of the devices has a different location. 

> The PCI location is not used because I wanted to avoid to nest device ids 
> (this is what you have to do if you can not rely on all USB controllers being 
> PCI devices). Usually the numbers dont change and even if they do it's not 
> too bad. I know that USB numbers are fragile, but using the location is 
> better than using nothing. 

What's the problem with USB controllers not being PCI? For every primary
bus (*) a location specifier can be defined. EISA is fine, it has slot
numbers.  ISA is a little problem, but because most ISA cards have the
I/O port jumpered (or stored with eeprom) you can use that (isa0300
would be a NE2000 card). ISAPnP is the most problematic, it has card and
function IDs and has i/o ports, but I'm not sure how stable those are.
Though we can't do much better than that.

(*) Primary busses are those that the CPU accesses directly without any
bus between.

> > Also, USB is a hierarchical bus, thus you can plug a hub into one of
> > the root ports and another hub into that one and so on. You can't stuff
> > all this into just one 'port number'. 
> 
> Sorry, that was wrong in my mail, the actual location scheme is already 
> <bus number>:<port of first hub>[:<port of second hub>...]

Ok.

> > Furthermore, in one port can be a
> > multifunction device, acting for example as both a keyboard and a mouse,
> > being seen as two different devices from userspace.
> 
> In my model this is seen as two driver instances using the same physical 
> device.

This is OK, then. "two driver instances" sounds a little weird, because
there is still just one driver handling both the keyboard and mouse
(hid), but oh well ...

> > approach the location string (PHYS) can be of arbitrary lengthm because
> > it's a tree path, it'd need another separator in addition to slash to
> > add the unique ID at the end of it.
> 
> Hmm.. looks very good. I'm not sure yet whether I like the idea of having two 
> or three IDs. 

I have no problem with it. ;) One for unique location (PHYS), one for
class (ID), one for optional unique identification within a class (UNIQ).

> PHYS is certainly superior to my approach (now that I understood the format 
> :), but I have to think of how to implement this.

The primary goals:

1) Uniquely identify a device connected to the system. Hotplug and
coldplug (machine turned off, cards/devices removed and added) safe,
doesn't change for devices that are connected the same way. Does change
for devices that are moved.

2) Easy to implement inside kernel. Simple concatenating of a string in
each driver. Most drivers already have some string identifiers (pci,
parport, isapnp, net, now also input, gameport serio) built in them.

3) Can work.

The primary design ideas:

1) It's bad to assume every driver has a userspace interface. Many of
the drivers don't. This is why the current kmod way of loading modules
based on userspace requests is failing.

2) Every driver can be described as a module that has one (or more)
input interface and one (or more) output interface. These interfaces
being typically via bus layer modules. With a little generalization we
have these busses currently:

pci, eisa, isa, isapnp, sbus - the classical primary ones
parport, gameport, serio, ide, scsi - the secondary busses
input, chardev, blockdev - 'virtual' busses ...

...  more like software layers, but behaving the same as busses from
kernels view, devices get registered and unregistered, etc. DevFS falls
quite clumsily into this, because it isn't integrated into the chardev
and blockdev layers and adds extra complexity. But it can be considered
a part of the chardev and blockdev layers, though device registration
must happen twice.

> PRODUCT should IMHO have the format "<busid>/<bus-specific-data>" because you 
> cannot assume that every bus has idvendor and idproduct. 

This is good for userspace interface. This isn't good for kernel,
because then device table parsing (upon module load and device connect)
is much more complex, you have to decode the bus-specific-data from
strings back to numbers.

> The serial number from the card is used to set the device id serial number 
> using devreg's API. The device is added by the bus driver using 
> device_register(). Later the device driver can change/set the serial number 
> using device_set_serialnumber(). However, when the driver is not loaded it 
> cannot provide a serial number, so it is possible that the serial number is 
> missing.

This is wrong, I think. The serial number of the device should be set
prior to registering it so that it is available when the system
processes the connect event. Note that for a typical cardbus netcard
it'll look like this:

1) Plug in the card
2) PCI bus gets a new device *without* a serial number
3) Hotplug agent sees the new connect and loads a netcard driver
4) netcard driver registers an 'eth' layer device, with serial number
   taken from SAPROM
5) Hotplug agent sees the new connect and configures the eth device
   according to the full PHYS (pci01:01.0/eth0), ID (pci:10b7:abcd),
   inherited from the PCI layer, and UNIQ (00:10:5A:6F:A1:66).

If the user changes the StationID of the card via ifconfig, then this
*won't* change the UNIQ id of the card, only the ethernet ID of the
card.

> Each driver has to register itself and all instances (in other words: has to 
> be patched).  /dev nodes are connected to the graph using a new 
> devfs_register function. The objects (driver instances, devices) are 
> internally identified using void pointers that can be freely defined per 
> driver or bus. For example the input layer uses struct input_dev pointers as 
> key for driver instances and PCI uses struct pci_dev pointers for PCI devices.
> 
> 
> > > <driver id> is the driver id of the driver that created the node (not the
> > > driver that handles the device). So in your case it would be "input", not
> > > "hid" for a USB device.
> > It'd most likely be evdev, or mousedev, or whatever. Input doesn't
> > create any devices, it just manages another (virtual) bus of devices,
> > much like the usbcore driver does.
> 
> Actually I use "input" in my port because it calls devfs_register() (in 
> input_register_minor()). Input is then connected directly to the driver that 
> calls input_register_device(). Evdev and mousedev don't appear as separate 
> drivers.
> 
> bye...
> 

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel