Using udev-extras for hardware-specific quirks?

[Daniel D Streetman]

devkit-devel-bounces at lists.freedesktop.org wrote on 06/03/2009 09:39:22 AM:

> Hello Dan,
>
> Dan Streetman [2009-06-01 12:13 -0400]:
> > I am creating udev rules for some system units I'm responsible for
> > enabling Linux on; specifically these systems have multiple serial
> > ports with labels on the ports like "A", "B", "C", etc.  However on
> > many of the units the hardware doesn't match the labelling so ports
> > "C" and above usually do not match the right serial node, i.e. while a
> > port labeled "C" should be /dev/ttyS2 it isn't.
>
> This is just a general property of current Linux, which is pretty much
> fully "hotplug" based. You cant't rely at all on any particular device
> ordering in general.

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.
The application cannot probe a serial port to tell what's connected.

> Distributions special-case some device classes
> such as network devices where (for historical reasons) eth0 must
> always be the same device. E. g. Ubuntu's installer creates a file
> /etc/udev/rules.d/70-persistent-net.rules  which looks like
>
> # PCI device 0x14e4:0x1600 (tg3)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:
> 1c:23:14:1c:2a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
> You can apply a similar "persistent naming" rule on your system.

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, the ports are always numbered exactly the same -
the problem is they are numbered wrong, i.e. not matching the labeling on
the physical system.

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?

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.

> > Anyway, my question is, is udev-extras the appropriate place for this
> > to live?
>
> I'm afraid not. Programs need to be fixed to not rely on a particular
> device name instead.

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?

>
> > DEVPATH=="/devices/pci0000:00/0000:00:13.1/0000:04:0b.1/tty/
> ttyS2", NAME="ttyS6"
>
> This really looks wrong. Since the initial naming isn't stable, the
> mapping isn't either. You need to identify a particular device on
> stable properties such as device names, serial numbers, or other
> constant properties.

For PCI-card based serial ports, there are no other device properties
besides the PCI address and kernel-assigned name.  Or do you know of any
other properties I can key off of?  I checked with "udevadm info -q all
-n /dev/ttyS2" for example and only DEVPATH and the simple name were
defined.

I'm more than willing to key off a hardware-specific constant key, but I
don't think a PCI serial port has any, besides the specific PCI
connectivity.  And even then, the entire PCI add-in card has a common PCI
address/path, so I don't see any way to distinguish each individual port on
the PCI serial card besides the port name...?

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/devkit-devel/attachments/20090603/38556e37/attachment.htm