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

[Tim Jansen <tim@tjansen.de>]

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