User-friendly disk names [LWN.net]

User-friendly disk names

Posted Jun 24, 2011 23:48 UTC (Fri) by mikov (guest, #33179)
In reply to: User-friendly disk names by dlang
Parent article: User-friendly disk names

Cr*p! I didn't know that. This adds to the ever growing list of beers that I should buy to various LWN members for valuable insights they provide. Are you in the Bay Area? :-)

You are saying that there is no theoretical way to identify the port in an USB hub where a device is inserted. So my scheme kind'a works only because it correctly identifies separate buses, and because already plugged devices in the same bus are enumerated in the same order. But if I start unplugging and plugging devices attached directly to a hub, I am screwed.

If I only could get my hands on the idiots who designed USB :-) Starting from the asymmetric connector and now down to this.

All that said, my complaint about the PCI device identification in the device model is still valid.

to post comments

User-friendly disk names

Posted Jun 25, 2011 0:44 UTC (Sat) by dlang (guest, #313) [Link] (15 responses)

in some ways it's worse than you think, the order devices are detected in when they are all plugged in at power up is partially determined by how fast each driver is initialized, a major speed change in a driver could change the order.

the thing you need to remember about USB is that is was initially designed for cheap, low-end, low speed devices like keyboards. Electrically it is a _very_ simple design.

you have four wires

power
clock
data
ground

the signaling over the data and clock wires is also pretty primitive (it's basically the i2c bus with a little more definition over the data standard)

all that a non-powered USB hub consists of is multiple sockets wired together (NO active electronics at all)

a powered hub is only required to add a power supply to this.

(now frequently hubs do add a bit more logic so that they can respond to queries from devices to answer how much power they can provide, but that's not a requirement of the USB 1.0 spec)

as for the funny connector, it was designed primarily to be cheap, then to be durable. it was copied from one of the popular console game systems that used it for the joysticks. They then made the ends of the cable different to make it impossible to plug things in incorrectly (and then people didn't like the size of the connector, so they made a different one, and a different one,.....)

over time things have gotten faster (by a factor of 100 or so), but everything is still backwards compatible so that you can take the oldest USB device and plug it into the newest system and things will work (everything on the bus will slow down to the speed of the slowest device on the bus, but it will function). USB was designed to be _extremely_ forgiving for slow or extremely low capability devices

device identification on USB is supposed by be done by a unique identifier in each device, but as USB interfaces have gotten cheaper (and moved from needing several chips, including separate rom/ram chips to being a tiny section of built-in logic 'thrown in' on a $5 chip in addition to the main functionality) the process and capability to give each device a unique serial number has fallen by the wayside (and/or cheap, short-sighted manufacturers have opted to shave pennies off their costs by not bothering to program the serial numbers on the devices) and the result is that sometimes there is no theoretical way to tell two devices apart once you are talking to them (you have to depend on what bus are they plugged into, which falls apart with hubs, at which point the only thing you can do is to depend on what order they were plugged in)

USB today is doing things never imagined by the designers, and in fact doing things that if you had asked the designers, they would have told you were explicitly _not_ in the world of things they designed USB for (due to the cost of implementing the interface with the technology of the time). For a lot of things that USB is being used for today, their answer would have been "use FireWire, it's designed for that sort of performance"

User-friendly disk names

Posted Jun 25, 2011 1:22 UTC (Sat) by mikov (guest, #33179) [Link] (14 responses)

Thanks for the background. I appreciate it.

In our case, we are using several USB to serial converters plugged into a couple of hubs. They are supposed to be the same, so it is not the manufacturers fault that they are indistinguishable by anything other than their physical connection. Unfortunately there is no reasonably priced alternative to USB,

A single multi-port USB to serial converter would address this nicely, but
we have evaluated about a dozen of them, and while all they work perfectly in Windows, they are either unsupported in Linux at all, or horribly broken (like dropping a byte every couple of hours). It is an embarrassing shame. I wish our company had the resources to sponsor somebody to fix that.

The only multi-port converter that worked well (other than not having its "non-free" firmware in Debian), and was reasonably cheap and available in the USA, was an old Keyspan 4-port model, which is no longer manufactured...

User-friendly disk names

Posted Jun 25, 2011 3:44 UTC (Sat) by dlang (guest, #313) [Link] (7 responses)

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

User-friendly disk names

Posted Jun 26, 2011 1:37 UTC (Sun) by mikov (guest, #33179) [Link] (4 responses)

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 (guest, #313) [Link] (3 responses)

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 (guest, #33179) [Link] (2 responses)

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 (guest, #313) [Link] (1 responses)

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 (guest, #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] (1 responses)

> 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

# diff <(lsusb -vvv -s 3:9) <(lsusb -vvv -s 3:8)
--- /proc/self/fd/11 2011-11-08 21:09:05.183873823 +0100
+++ /proc/self/fd/12 2011-11-08 21:09:05.183873823 +0100
@@ -1,5 +1,5 @@

-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 (guest, #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.

USB Serial port woes

Posted Jun 26, 2011 16:31 UTC (Sun) by speedster1 (guest, #8143) [Link] (3 responses)

> A single multi-port USB to serial converter would address this nicely,
> but we have evaluated about a dozen of them, and while all they work
> perfectly in Windows, they are either unsupported in Linux at all,
> or horribly broken (like dropping a byte every couple of hours).
> It is an embarrassing shame. I wish our company had the resources
> to sponsor somebody to fix that.

Do they _really_ work perfectly in Windows? In my experience, cheap serial converters are prone to dropping a byte now and then, and when I searched online it turned out that it was hardware not drivers -- Windows users would experience the same problem given the same level of usage and attention to detail (it just happens a lot less often, because there are more of us Linux developers making heavy use of serial ports).

Sorry I can't find an actual reference explaining the hardware issue on a common PLX usb-serial chip; there is no sufficient replacement yet for the recently-discontinued Google Linux search :`-(

I agree that keyspan did not have these problems, but they were significantly more expensive and seem to have lost out to the even cheaper but somewhat flaky adapters...

If there are current multi-port adapters that really do have higher quality chips in them (i.e. like keyspan rather than PLX) but lack Linux drivers, then somebody should get in touch with the Linux Driver Project and donate such an adapter!
http://www.linuxdriverproject.org/

USB Serial port woes

Posted Jun 27, 2011 3:34 UTC (Mon) by mikov (guest, #33179) [Link] (2 responses)

It is difficult for me to say how good they really were in Windows, since it didn't matter. We needed them in Linux and we only did tests in Windows to make sure a specific unit wasn't defective. They definitely did behave measurably better in Windows - after comparable amount of testing there weren't any dropped bytes.

There is one additional piece of information however, which can explain at least part of what I saw:

Most of the multiport USB-to-serial adapters are in fact a USB hub with ordinary single-port adapters hanging from it. The problem is that the hub is USB 2.0 while the serial adapters themselves are USB 1.0. Linux kernels at least up to 2.6.26 had a bug where USB 1.0 devices did not work reliably behind a USB 2.0 bridge.

I have complained about this problem before on LWN and I got advice to try other config settings, which I did, but saw no improvement.

I am not 100% sure the problems were caused by this and it is also possible that it has been fixed in later kernel versions.

USB Serial port woes

Posted Jun 27, 2011 16:35 UTC (Mon) by speedster1 (guest, #8143) [Link] (1 responses)

Here is a complaint about single-port Prolific PL2303 adapters, with which I've experienced reliability issues (note I meant to say "Prolific" not "PLX" in previous comment; PLX makes perfectly good PCI bridges, not cheap USB chips). It makes the observation about dropped bytes, but doesn't have an explanation about why they are prone to occasional data loss; I think that was in a forum post not a mailing list post, and I still can't find it.

http://article.gmane.org/gmane.comp.monitoring.nut.user/5...

If your problem is instead a more generic 2.0 hub driver problem, could you post a link discussing it? With details, I might be able to go check commit messages to see if it has supposedly been fixed.

USB Serial port woes

Posted Jun 28, 2011 4:29 UTC (Tue) by mikov (guest, #33179) [Link]

OK, I will look for the link and post back here.

BTW, we have been using PL2303 USB-to-serial adapters and we haven't had any issues with them, as long as (important!) USB 2.0 is disabled.

User-friendly disk names

Posted Nov 3, 2011 8:46 UTC (Thu) by gebi (guest, #59940) [Link]

have you already looked at the ftdi 4port chips?
never had a problem with them, and we are using them a _lot_.

User-friendly disk names

Posted Nov 13, 2011 14:29 UTC (Sun) by Baylink (guest, #755) [Link]

Computone Intelliport Terminal Server.

It's TCP instead of USB, but do you really care? :-)