This USB device (a Palm) has 2 serial interfaces. Only one of them is to be used
for data connection to the desktop. Right now, it's not possible, other than
through hackery on the device name, to distinguish which is which.
$ udevinfo -a -p `udevinfo -q path -n /dev/pilot0` > /tmp/pilot0
$ udevinfo -a -p `udevinfo -q path -n /dev/pilot1` > /tmp/pilot1
$ diff -u /tmp/pilot0 /tmp/pilot1
--- /tmp/pilot0 2005-05-06 16:31:15.946538800 +0100
+++ /tmp/pilot1 2005-05-06 16:31:19.326989050 +0100
@@ -5,13 +5,13 @@
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
- looking at class device '/sys/class/tty/ttyUSB0':
+ looking at class device '/sys/class/tty/ttyUSB1':
follow the class device's "device"
- looking at the device chain at
+ looking at the device chain at
looking at the device chain at
Only differences are the ID of the USB connection, the minor number of the
device, and the different device name.
I don't think RHEL should take leadership in defining these sorts of
interfaces. It's something Fedora should do. However, if you have
a concrete proposal, and it you have a buy-in from gpilot or evolution folks,
I'm all ears. I can help to push this to Greg Kroah and thus to Linus.
Please educate me here; links to mailing list archives would be helpful.
I can't yet get buy-in from the Evo/gnome-pilot folks, as there's no code there
to detect the Palms. The buy-in (David?) would probably first be from HAL, where
interested applications can get the information about the index. After that,
it's quite simple to have a property saying "This is the data port to use".
The main problem is that HAL can't know about that, because the kernel doesn't
export this property. Something like an INDEX property would be good enough.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.