From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vojtech Pavlik Date: Sat, 29 Sep 2001 08:47:55 +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 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 > :[:...] 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 "/" 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. > > > > > 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