From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vojtech Pavlik Date: Sat, 29 Sep 2001 18:04:04 +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 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 "/" 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