Re: Using udev-extras for hardware-specific quirks?
Dan Streetman <ddstreet <at> us.ibm.com>
2009-06-03 20:44:39 GMT
On Wed, Jun 3, 2009 at 12:56 PM, Martin Pitt <martin.pitt <at> ubuntu.com> wrote:
> Hello Daniel,
>
> Daniel D Streetman [2009-06-03 10:48 -0400]:
>> Well that is the problem, isn't it? With serial ports there is absolutely
>> nothing to go on to tell what physical port it is except for numbering.
>
> Right, that might be more tricky. I actually can't test it here, it's
> been a long time since I had a machine with a real serial port.
>
>> Well, I don't think this will work as the problem isn't consistent naming -
>> serial ports are not added/removed and so there is no danger of
>> inconsistent numbering
>
> I wouldn't rely too much on it. Ethernet cards aren't added/removed
> either, and yet without the persistency rules they get a pretty much
> random order on boot. I guess the ordering is more reliable for serial
> ports since they are all covered by the same driver (unlike the two
> ethernet cards I used to have).
>
>> I could create permanent "persistent naming" rules such as the above one to
>> correctly number the ports, but I don't think that is what you mean - you
>> mean I should create a dynamic rule to create those persistent naming rules
>> on-the-fly as serial ports are (first) detected. That is what you mean
>> right?
>
> Not really on the fly, just attaching the name to a physical attribute
> which stays constant across reboots. If there is none, then I guess
> you can keep your current rules which just rename the interfaces.
>
>> Also to clarify, I'm not looking to create a rule for just my system - I am
>> trying to create a permanent rule that I can upstream into a common
>> repository that all distributions can draw from so the various quirks on
>> these systems can be correctly handled by all distributions.
>
> Right, I understood your intention, but I don't think we want
> arbitrary renaming like that, since they are going to have a different
> effect on every machine anyway,
Well I am using the system vendor/product IDs from dmi so the rules
would only apply for the specific systems I'm working on - on any
other systems they would be skipped entirely. I was hoping that
udev-extras would be the right place to put system-specific quirks
like this.
> and one order is as good as the other
> usually.
Well, not in my case. Customers expect the numbering to match the labeling.
>
>> With serial ports? How can an application not rely on the serial port
>> number? For other types of interfaces, USB devices, ethernet interfaces,
>> displays, whatever - I can understand that. But ever since serial ports
>> were invented, the port number is the one and only thing the application
>> can use. Right?
>
> Right, that's true. Probably one of the reasons why they are
> considered "legacy".
>
> Usually, when there is a device on a port, there is often a way to
> probe that device instead of the port it is attached to (which is what
> you actually want in most cases). That needs an external probe program
> with RUN/IMPORT, and is very specific to the type of hardware you
> attach.
>
>> For PCI-card based serial ports, there are no other device properties
>> besides the PCI address and kernel-assigned name.
>
> The PCI device should have an unique physical slot name
> (PCI_SLOT_NAME), but that won't help you, since I guess one PCI device
> drives all of your serial ports?
For this particular system, yep. There are 2 standard ports on the
mainboard, ttyS0 and ttyS1, and a single (integrated) PCI chip that
provides the rest. So none of the PCI hardware's information helps to
distinguish between any of the individual ports it provides. I could
check each port's irq and ioport information, but I suspect that is
even more dynamic, as I assume the PCI serial driver probably can
assign whatever IRQ and ioport addresses it wants to its ports. Maybe
I should get into the PCI serial driver and see how static or dynamic
it really is with numbering/naming and with IRQ/ioport assignment...
>
> So I think you should either locally keep your current renaming,
Well my choices are either maintain these udev rules and ship them to
customers as an add-on, or get the udev rules upstream somewhere so I
don't have to ship it specifically to customers. As maintaining the
udev rules myself is not really the Open Source way of doing things
(plus it's more work for me and all customers), I would of course
prefer to upstream the udev rules. I do have a SysV init (bash)
script (that I inherited) that was previously sent to any Linux
customers that remaps the serial ports to match the labeling. I would
prefer to do it the right way (or at least "better" way) instead of
continuing to maintain and ship that to customers.
So if udev-extras isn't the right place for this, any suggestions on
where might be the right place? Or do you think I should try a
completely different approach instead of udev rules?
I will mention again that the rules I am proposing are system
vendor/product-specific, i.e. they will be skipped entirely on systems
whose DMI info does not match. In the example I included I did leave
out one line (the lone GOTO) so it should have read:
SUBSYSTEM!="tty", GOTO="ibmrss-serial-end"
PROGRAM="/bin/cat $sys/class/dmi/id/board_vendor"
RESULT!="IBM*", GOTO="ibmrss-serial-end"
PROGRAM="/bin/cat $sys/class/dmi/id/board_version"
RESULT=="4800783", GOTO="ibmrss-serial-4800783"
GOTO="ibmrss-serial-end"
LABEL="ibmrss-serial-4800783"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS2", NAME="ttyS6"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS3", NAME="ttyS7"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS4", NAME="ttyS2"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS5", NAME="ttyS3"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS6", NAME="ttyS4"
DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/ttyS7", NAME="ttyS5"
GOTO="ibmrss-serial-end"
LABEL="ibmrss-serial-end"
So for this case unless the DMI vendor string matches "IBM*" and the
version string matches "4800783" then the rule is not applied. I
would add more rules for each of the system units with this serial
port remapping quirk (which is several). The GOTO logic could be
changed of course if it should be different. I also think the DMI
product_vendor and product_version is better to use instead of
board_vendor and board_version, but that's just details.
> or perhaps just swap the stickers to have the correct number :)
Well it's screen printed onto tens of thousands of units, many of
which are already shipped to customers so that probably would be
tough. 
>
> Martin
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
> _______________________________________________
> devkit-devel mailing list
> devkit-devel <at> lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>
_______________________________________________
devkit-devel mailing list
devkit-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
RSS Feed