* Re: IDs (was Re: Hotplugging for the input subsystem)
2001-09-28 22:34 IDs (was Re: Hotplugging for the input subsystem) Tim Jansen
@ 2001-09-28 23:07 ` Vojtech Pavlik
2001-09-29 1:15 ` Tim Jansen
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Vojtech Pavlik @ 2001-09-28 23:07 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IDs (was Re: Hotplugging for the input subsystem)
2001-09-28 22:34 IDs (was Re: Hotplugging for the input subsystem) Tim Jansen
2001-09-28 23:07 ` Vojtech Pavlik
@ 2001-09-29 1:15 ` Tim Jansen
2001-09-29 8:47 ` Vojtech Pavlik
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Tim Jansen @ 2001-09-29 1:15 UTC (permalink / raw)
To: linux-hotplug
On Saturday 29 September 2001 01:07, Vojtech Pavlik wrote:
> > 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").
> 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.
> 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.
> 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>...]
> 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.
> 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.
> > 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.
> 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.
> > 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?
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.
> > <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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IDs (was Re: Hotplugging for the input subsystem)
2001-09-28 22:34 IDs (was Re: Hotplugging for the input subsystem) Tim Jansen
2001-09-28 23:07 ` Vojtech Pavlik
2001-09-29 1:15 ` Tim Jansen
@ 2001-09-29 8:47 ` Vojtech Pavlik
2001-09-29 12:31 ` Tim Jansen
2001-09-29 18:04 ` Vojtech Pavlik
4 siblings, 0 replies; 6+ messages in thread
From: Vojtech Pavlik @ 2001-09-29 8:47 UTC (permalink / raw)
To: linux-hotplug
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
> <bus number>:<port of first hub>[:<port of second hub>...]
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 "<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.
> 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.
>
>
> > > <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...
>
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IDs (was Re: Hotplugging for the input subsystem)
2001-09-28 22:34 IDs (was Re: Hotplugging for the input subsystem) Tim Jansen
` (2 preceding siblings ...)
2001-09-29 8:47 ` Vojtech Pavlik
@ 2001-09-29 12:31 ` Tim Jansen
2001-09-29 18:04 ` Vojtech Pavlik
4 siblings, 0 replies; 6+ messages in thread
From: Tim Jansen @ 2001-09-29 12:31 UTC (permalink / raw)
To: linux-hotplug
On Saturday 29 September 2001 10:47, you wrote:
> 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.
> > 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".
> > 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?)?
> 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.
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IDs (was Re: Hotplugging for the input subsystem)
2001-09-28 22:34 IDs (was Re: Hotplugging for the input subsystem) Tim Jansen
` (3 preceding siblings ...)
2001-09-29 12:31 ` Tim Jansen
@ 2001-09-29 18:04 ` Vojtech Pavlik
4 siblings, 0 replies; 6+ messages in thread
From: Vojtech Pavlik @ 2001-09-29 18:04 UTC (permalink / raw)
To: linux-hotplug
On Sat, Sep 29, 2001 at 02:31:38PM +0200, Tim Jansen wrote:
> > > 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".
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.
> > > 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.
> > 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.
>
> 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.
> 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 ...
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread