Re: IDs (was Re: Hotplugging for the input subsystem)

[Tim Jansen <tim@tjansen.de>]

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