IDs (was Re: Hotplugging for the input subsystem)

[Tim Jansen <tim@tjansen.de>]

On Friday 28 September 2001 20:09, you wrote:
> PRODUCT: idbus/idvendor/idproduct/idversion. Idbus is defined in
> 	 input.h, the rest is in bus specific includes, ie for PCI
> 	 idvendor and idproduct are from pci_ids.h.
> UNIQ: Unique device ID. If non-empty, and present, then this is a string
> that is unique for each device with the idbus/idvendor/idproduct/idversion
> combination. Typically a serial number. Not all devices have
> 	this.
> PHYS: Physical path of the device. This is defined to be constant if the
> 	device is plugged to the same port in the system and unique for all
> 	connected devices. It has the form: busX.X/busX.X/busX.X ...,
> 	where bus is bus type, X.X is bus address, typically slot or
> 	port, entries are slash delimited. Examples:

It would be great if we could find a common format for ids in general and 
your UNIQ and PHYS ids in particular. In my devreg system 
(http://www.tjansen.de/devreg) I defined similar id schemes. The problem is 
that for each subsystem and for each bus there are now different id schemes 
which is certainly not a good idea.

Here are the id types and schemes of the next devreg version (and the 
rationale behind them):

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


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").


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>

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

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

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


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.


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


bye...


_______________________________________________
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