From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vojtech Pavlik Date: Fri, 28 Sep 2001 23:07:24 +0000 Subject: Re: IDs (was Re: Hotplugging for the input subsystem) Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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: > /// 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 ":" as location and " id>::" 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 ":" as location and " 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: > /// > > 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"). > 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). > 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. > 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