From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Jansen Date: Sat, 29 Sep 2001 12:31:38 +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 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 "/" 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