IDs (was Re: Hotplugging for the input subsystem)
Quoted 4 lines · you
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 frompci_ids.h.
UNIQ: Unique device ID. If non-empty, and present, then this is a string
Quoted 8 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Tim Jansen
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.
Quoted 10 lines
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?
Quoted 22 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
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.
Quoted 13 lines
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.
Quoted 3 lines
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?
Signature · 7 lines
Vojtech Pavlik SuSE Labs _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Vojtech Pavlik
Quoted 6 lines
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.Ok. Is this needed for anything?
It's in the device node id and I also use it for references between driver (for example that "hid" uses "input").
Quoted 3 lines
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.
Quoted 6 lines
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.
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.
Quoted 3 lines
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>...]
Quoted 3 lines
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.
Quoted 9 lines
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.
...
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.
Hmm.. looks very good. I'm not sure yet whether I like the idea of having two or three IDs.
PHYS is certainly superior to my approach (now that I understood the format :), but I have to think of how to implement this.
PRODUCT should IMHO have the format "<busid>/<bus-specific-data>" because you cannot assume that every bus has idvendor and idproduct.
Quoted 7 lines
Quoted 4 lines
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.
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.
Quoted 3 lines
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.
I misunderstood the "input0" in your example. It's role more like my <driver instance> and <driver id> combined, only that it is device-centric and not driver-centric.
Quoted 5 lines
Quoted 3 lines
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 deviceThis is useful. Where do you get the info from?
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.
Quoted 6 lines
Quoted 3 lines
<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...
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Tim Jansen
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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 ...
Quoted 6 lines
Quoted 3 lines
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).
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
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 usingdevice_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.
Quoted 22 lines
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_registerfunction. 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 structinput_devpointers as key for driver instances and PCI uses structpci_devpointers for PCI devices.Quoted 6 lines
Quoted 3 lines
<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()(ininput_register_minor()). Input is then connected directly to the driver that callsinput_register_device(). Evdev and mousedev don't appear as separate drivers.bye...
Signature · 7 lines
Vojtech Pavlik SuSE Labs _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · you
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 ...
My terminology is:
driver = a piece of code that's loaded into kernel (would be the class in OO) driver instance = something that exists per device. For example the struct hid_device in the hid driver (object in OO)
The hid driver uses two separate struct hid_devices for mouse and keyboard, so it should be easy in this case. It's worse in drivers like psaux that don't actually support instances and maybe even handle several devices at the same time.
Quoted 4 lines
Quoted 2 lines
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).
It makes APIs complicated and would probably confuse user space programmers. I have a user space library that parses the information from the kernel and has functions like "here is my device id, give me an object that describes the device". If there are three IDs people will ask why they always have to use three IDs even though they have to be used together.
I see the point of not having to parse the id, but on the other hand the logic shouldn't be re-implemented in every user space program with the risk that someone doesn't understand the concept, so a library that cares for finding devices would be a neat thing anyway.
For the user space (not the hotplug scripts, but for normal applications) I would really be more comfortable with unified id like "PRODUCT;PHYS;UNIQ".
Quoted 6 lines
Quoted 2 lines
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.
But what happens if tomorrow there is a new bus without idvendor and idproduct, and instead a 128-bit random number for identification (didn't Firewire use something like this?)?
Quoted 9 lines
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).
Quoted 3 lines
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.
Then the device couldn't be visible before a driver is loaded. Devices without driver couldn't be seen in my device registry then, which is certainly not a good idea.
bye...
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Tim Jansen
Quoted 4 lines
Quoted 2 lines
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).
Quoted 11 lines
It makes APIs complicated and would probably confuse user space programmers. I have a user space library that parses the information from the kernel and has functions like "here is my device id, give me an object that describes the device". If there are three IDs people will ask why they always have to use three IDs even though they have to be used together.
I see the point of not having to parse the id, but on the other hand the logic shouldn't be re-implemented in every user space program with the risk that someone doesn't understand the concept, so a library that cares for finding devices would be a neat thing anyway.
For the user space (not the hotplug scripts, but for normal applications) I would really be more comfortable with unified id like "PRODUCT;PHYS;UNIQ".
Ok. Though I'd prefer PRODUCT;UNIQ;PHYS or PHYS;PRODUCT;UNIQ. Because PRODUCT and UNIQ are bound together. UNIQ is only defined to be unique in the PRODUCT class of devices, not globally.
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
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.
But what happens if tomorrow there is a new bus without idvendor and idproduct, and instead a 128-bit random number for identification (didn't Firewire use something like this?)?
You convinced me, a string is more versatile. After all, the kernel also can have a library for the matching.
Quoted 9 lines
Quoted 9 lines
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).
Quoted 5 lines
Quoted 3 lines
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.
Then the device couldn't be visible before a driver is loaded.
The only device that would be seen would be the PCI device. Which is all that you can make visible without a device specific driver loaded. It will, of course, have no serial number, because PCI devices don't have serial numbers.
Quoted 2 lines
Devices without driver couldn't be seen in my device registry then, which is certainly not a good idea.
I think it is not a problem. Because only after loading the device you'll be able to see the ETH device, with its serial number, etc. It could also have been something completely different, say UHCI controller
...
There really is no reason to set the serial number taken from the SAPROM on the PCI device ...
Signature · 7 lines
Vojtech Pavlik SuSE Labs _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel