Le mardi 29 novembre 2005 à 09:39 -0800, Greg KH a écrit :
> On Tue, Nov 29, 2005 at 02:23:05PM +0100, Xavier Bestel wrote:
> > I could easily write a rule that would create a /dev/pl2303 (or
> > whatever)
>
> What happens if you plug in more than one device like this? I know
> people who sync more than one palm device all the time.
I don't know. There's already a similar rule for /dev/pilot, udev could
create /dev/pilot0 and /dev/pilot1, but then we're back at square one.
I really wonder how the people you're talking about do. It seems
impossible through USB because the usbserial ports numbers seem pretty
random (= not only dependant on the palm device) to me.
[...]
> > I understand that having it for all devices kind is a bit troublesome,
> > and I'm beginning to believe device persistence can't be solved without
> > some state saved somewhere, preferably by the application.
> >
> > I have to think a bit more about it.
>
> Good luck, writing a rule for all palm devices is _hard_, if not
> impossible due to the wide variety of devices, and what port is supposed
> to be used for syncing with (some devices lie about this, and you don't
> know for sure until you try to actually sync with them.)
That's why I think application should keep state. What I imagined was:
- The application somehow gets a handle on the device node
(e.g. "/dev/pl2303").
- The app calls a udevinfo variant which returns something like:
NAME=/dev/pl2303
BUS=="usb"
ID=="1-3"
DRIVER=="usb"
SYSFS{idProduct}=="2303"
SYSFS{idVendor}=="067b"
SYSFS{manufacturer}=="Prolific Technology Inc."
SYSFS{product}=="USB-Serial Controller"
etc.
and stores these parameters somewhere.
- Next time the app wants to connect to the same device, it calls
something (let's name it "udevmatch") with these parameters.
udevmatch will try to match the parameters with the devices present
in /dev depending on some policy (e.g. first match the product and
manufacturer, if there are several matches try the connection id ..)
and returns zero, one or many prioritized device node(s).
> Marco did the right thing in closing this :)
Yes, custom udev rules are really ad-hoc and apparently HAL is the magic
bullet - but I have yet to learn how it works.
Xav
