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

[Vojtech Pavlik <vojtech@suse.cz>]

On Sat, Sep 29, 2001 at 12:34:50AM +0200, Tim Jansen wrote:

> bus id
> ==> Identifies a bus subsystem like the USB like the PCI bus or USB. This is the 
> equivalent of your "idbus" field in PRODUCT.
> 
> format:  simple alphanumeric string in lower case, e.g. "pci", "usb", 
> "ieee1394", "sbus". 

Ok. With the comment that ieee1394 is not nice because it contains a
number.

> driver id
> ===
> Identifies a loaded driver (a driver can consist of one or more modules, or 
> be compiled into the kernel). Drivers can be layered. This is neccessary for 
> the equivalent of your PHYS id if you want it to apply to other drivers as 
> well.
> 
> format: for existing drivers the name of the main module without ".o" ending  
> (for example "pwc" or "hid"); for new drivers a DNS name to avoid name 
> clashes (like "quickcam.sf.net").

Ok. Is this needed for anything?

> unique device id
> ======
> Identifies a physical device. It is basically a moniker for physical device 
> instances for user space processes. A user-space process can use it to find a 
> device.
> My goals were: 
> 1. User-space code that uses the device id does not have to know anything 
> about the bus or driver for matching device ids
> 2. The device id should still be valid after a reboot or hot-unplugging. Even 
> if it is plugged into a different port it should be recognized. 
> 3. Each device that is connected to the system has a unique id, even if two 
> devices are identical (= same product, but possibly different serial 
> numbers). It can not be guaranteed that two identical devices that are not 
> connected to the system have different device ids because the location is not 
> known and not all devices have serial numbers.
> 4. If two identical devices without support for serial numbers are connected 
> to the system it should be possible to identify them using the location (e.g. 
> which port the devices are connected to). This is often the only way to 
> identify devices that are connected to serial ports or to identify PCI cards 
> without serial number.
> 
> 
> format: 
> <bus id>/<bus dependent location>/<bus dependent device description>/<serial 
> number>

In my opinion this isn't enough, because it's a flat model. My PHYS uses
a tree model, which is much more powerful, see below.

> Examples for device ids are 
> pci/0:7/1106:686:0/
> 
> The PCI driver uses "<bus number>:<slot number>" as location and "<vendor 
> id>:<model id>:<function number>" for the device description. Serial numbers 
> are not supported by the PCI driver, but the device drivers can set it (for 
> example a ethernet driver can use the MAC address).

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.

> usb/1:0/58f:9213/0001
> The usb driver uses "<bus number>:<port number>" as location and "<vendor 
> id>:<model id>" as device description. Serial number is the USB serial number 
> (BTW this example shows why you should never trust a USB serial number, the 
> example is from a Macally iKey keyboard). 

This is a problem. USB bus numbers aren't hotplug safe. They are
allocated on first-init-first-get-number basis. With CardBus and HotPlug
PCI and with stuff as simple as loading ohci driver before the uhci one
or vice versa you get different USB bus numbers on subsequent powerups.

The only method to identify the USB busses is by the underlying bus, ie
PCI slot location, not by USB bus number.

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

So, you need a tree model to avoid ad-hoc bus number asignments. Take
the Panther trackball as an example. It's a device that plugs into a
gameport, and itself consists of a trackball device and another gameport
(advanced, with ADC), which you can connect a joystick to. Now imagine
how you'd your device id work:

gameport/2/11:02/

The gameport number would have to be assigned somehow, most likely on a
init-order basis. This is wrong, because I can plug a CardBus gameport
card in the meantime and all numbers will be different. My approach
describes the devices as a tree:

pci0:4.0 				-- The sound card.
pci0:4.0/gameport0			-- The first (only) gameport on the soundcard
pci0:4.0/gameport0/input0		-- The trackball device of the Panther
pci0:4.0/gameport0/gameport0  		-- The first (only) gameport of the Panther
pci0:4.0/gameport0/gameport0/input0 	-- The joystick connected to the Panther gameport.

Similarly:

pci1:01.0				-- CardBus card
pci1:01.0/eth0				-- The ethernet of the card

pci0:07.1/usb0:2.3.1/input0		-- Mouse connected via several hubs to a PCI USB card

Note that all the strings won't change when the init order is different,
when you add other cards, etc. Also note that the strings match exactly
the arrangement of driver layers (not the drivers themselves) in the
kernel.

> Comparing two device ids is more complicated than just comparing two strings. 
> There are three kinds of comparisons with different probabilities that both 
> devices ids represent the same device instance.
> 1. If both device ids are completely identical, you can be sure that both 
> devices are the same. 

Are the same and were plugged into the same spot as they were before.

> 2. If only the location is different you can be quite sure that it is the 
> same device, only plugged into a different port; especially if the serial 
> number is set

This is why I have split the location and unique ID, because in my
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.

> 3. If the location and serial number are different, but one of the serial 
> numbers is empty it is still possible that the devices are the same. This is 
> because the serial number is sometimes set by the device driver (like in pci 
> ethernet drivers). If the driver was not loaded when the device id has been 
> created then the serial number is empty.

Ugh? Which PCI ethernet drivers create the serial? All ethernet cards
are REQUIRED to have an SAPROM in them and that makes them all unique,
without that ethernet wouldn't work.

However, this case is still important:

4. Same location, different ID: Someone has replaced the device with
something else. This may be because the previous device was faulty. If
it is the same type device (ethernet, mouse, whatever), we should assume
the new device is taking the old ones role.

> device node id
> =====> The device node id is my equivalent of your PHYS id and a new feature of the 
> next devreg version.  It identifies a driver's /dev node (and a major/minor 
> pair for those without devfs) that has been created by a driver for a 
> physical device. A user space process can store it to find the physical 
> device's special file at a later time, even if it is represented by a 
> different /dev node. It could also be used in the kernel to map device node 
> ids on /dev nodes and major/minor numbers, this way you can get stable device 
> nodes.

I think you misundrestood the PHYS meaning then - it has no relation to
the /dev hierarchy, it really only describes the true physical location
of the device as seen by the kernel. 

> format:
> <node name>/<driver instance>/<driver id>/<device id>
> 
> <node name> is a moniker that is set by the driver that created the device 
> node.  Usually it should be the name of the node without trailing number (for 
> example "ttyS", "event" or "dsp").
> <driver instance> can be set by the device driver if the driver has several 
> instances handling the same device. For example if you have a USB device with 
> two independent HID interfaces you could use this to differentiate the event 
> interfaces (because the device id is per device).
> <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.

> Devreg exports the relations between drivers so you 
> can easily find out which device driver instance uses which "input" instance.
> <device id> is the device id of the physical device 

This is useful. Where do you get the info from?

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