each serial adapter should have a unique serial number, you should be able to define the udev rules based on that, at that point it won't matter what order they are detected in. this will have headaches when you move adapters from one machine to another, but you could label each adapter with it's own number and make the resulting device name include that number
Posted Jun 26, 2011 1:37 UTC (Sun) by mikov (subscriber, #33179)
[Link]
That is a good idea, but tracking each converter's serial number and manually configuring each machine with it is not practical in a manufacturing process.
However I see how a hybrid solution could work. Our current approach with PHYSDEVPATH does work if all devices are plugged in, so knowing that this the case we could use it to automatically generate a one time mapping from a USB serial number to location. It is still a pain because the mapping will have to be re-generated if a converter is replaced (and they do fail out in the field, being the cheap pieces of garbage that they are), but it is a conceptually robust solution.
Sigh, I do miss the olden days of ISA, i2c and even PCI. Now PCIE has been relegated to being a "server technology" in practice.
User-friendly disk names
Posted Jun 26, 2011 3:02 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
how is setting up a one-time mapping of serial numbers to physical mapping different from setting up serial number to function mapping?
as for other technologies,
i2c has the exact same problem as USB, the only identity possible is what's reported by the device.
PCI has a slot number ID, but I've seen different versions of the kernel detect the multiple PCI buses in a different order
ISA didn't have any slot identifier, everything was based on the configuration of the individual board.
depending on how many of these serial adapters you need, your best bet may be to buy them from a more upstream provider, you could probably get someone to program a bunch of them with a set of identifiers (i.e. if you need 5 serial ports, get a bunch of them labeled and electronicly identified as #1, a bunch as #2, etc), then your udev rules could map them properly and your only limitation would be that you only replace a #1 with a #1
User-friendly disk names
Posted Jun 27, 2011 3:17 UTC (Mon) by mikov (subscriber, #33179)
[Link]
It is conceptually the same, but when you are dealing with production you you have to think about how to reliably and cheaply duplicate this for hundreds of devices. The device serial number is useless unless you have a way to _automatically_ map it to a physical location.
About PCI: you don't use the bus number at all. The sequence of PCI device:function id-s starting from the root bridge through all downstream bridges and ending at the device gives you a guaranteed unique mapping for that hardware regardless of BIOS, kernel, etc. You only need to define a mapping once for a motherboard/CompactPCI chassis and you get a reliable physical slot identification. That is how it is supposed to work and incidentally that is how Windows identifies its PCI devices.
udev and sysfs provide the same information, so it is technically possible to get the same functionality in Linux.
In a previous life I had to do stuff like hack an embedded PC BIOS and Windows bus driver to support huge numbers of PCI devices. The BIOS code was so bad it was scary (to this day I am impressed that PCs can boot at all), but the PCI bus itself at the logical level was a joy.
So purely as a user of USB, I naively believed that it was similar to PCI.
And I am surprised you commented on i2c. It is fundamentally different from USB - the device ids are fixed, or you can choose a bit at most (in hardware). There is no plug and play. Often you can't even have two devices of the same kind on the same bus. It takes half an hour to implement I2C from scratch via bit banging :-)
And ISA. Oh, ISA... It didn't have slot id-s, but it did have jumpers :-) Not to mention you could actually build an ISA board from scratch and do the decoding manually with wires... Good times.
User-friendly disk names
Posted Jun 27, 2011 3:33 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
Ok, I've seen PCI devices get identified in different orders after a kernel update, so I assumed that part of the identification depended on the order that things are scanned.
as for USB vs i2c, if you look at the low-level over-the-wire protocol, i believe that USB is really a superset of i2c. you can bit-bang a USB interface as well, (although not very efficiently), USB adds an additional layer of software and standard definitions over the raw wire protocol.
I could be mistake, but when I first learned about USB I was looking very closely at i2c for other things and I remembering that they were extremely similar at the hardware/signaling level
User-friendly disk names
Posted Jun 27, 2011 4:12 UTC (Mon) by mikov (subscriber, #33179)
[Link]
I have no doubt that you are correct about the i2c and USB similarity. If USB hubs are as dumb as you are describing, then the only way to identify a device is through some unique number (call it address, id, serial number, whatever). So you can't have two devices with the same USB serial number on the same bus. Exactly the same as i2c.
I think my point, to the extent that I even have a point beyond just being nostalgic about times when there was more direct control over hardware, is that in I2C there is no discovery. The device type is the device address. The devices and their ids are by definition fixed and known in advance. So, the question of identifying the physical location of a I2C device doesn't even exist. I2C is good for what it does.
With USB by contrast, you are identifying devices that look externally the same by a hidden magic serial number. There is a fundamental usability problem.
If I have two USB mouses which are _exactly_ the same, why do they need appear as separate devices to the computer? That makes no sense at all. If I plug them in the same PC at the same time, the only thing that really differentiates them is the USB connector.
Imagine a hypothetical product where users can interact with multiple virtual machines running on the same PC, using multiple video cards, mice and keyboards. It is pure idiocy to have to associate the keyboards and mice to the virtual machines by their unique USB serial number rather than the USB connector where they are plugged.
In other words, ideally USB hubs should have been designed to function like PCI-PCI bridges. Oh well, that is not a Linux problem :-)
User-friendly disk names
Posted Nov 8, 2011 20:13 UTC (Tue) by jo42 (subscriber, #59640)
[Link]
> each serial adapter should have a unique serial number
Where can I find this serial number? I've the same problem.
# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 003 Device 005: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 003 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 003: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-Bus 003 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
+Bus 003 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
bLength 18
bDescriptorType 1
User-friendly disk names
Posted Nov 8, 2011 22:14 UTC (Tue) by jimparis (subscriber, #38647)
[Link]
My PL2303 devices don't have a unique serial. I don't know if the
chip supports that. If your device does, then you can use the links in /dev/serial/by-id. Otherwise, the links in /dev/serial/by-path are probably your best bet.