DEVICE and usb strategy

DEVICE and usb strategy

[Andreas Jellinghaus]

what is the current strategy for usb and DEVICE in udev?

for example:
 - /proc/bus/usb not mounted
 - /dev/bus/usb is present
 - what should be in DEVICE ?

currently I have a situation with (k)ubuntu dapper / udev 079
in this case: my application gets called, but with DEVICE pointing
to /proc/bus/usb/... and that does not exist.

Sure, I can add magic code to my application. But before doing so
I would first like to know if there is a consensus what should be
in DEVICE and whos job it is to set it properly / handle alternative
locations. so, what is the strategy on this?

Thanks, Andreas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: DEVICE and usb strategy

[Kay Sievers]

On Sun, Mar 19, 2006 at 09:36:26PM +0100, Andreas Jellinghaus wrote:
> what is the current strategy for usb and DEVICE in udev?

Ignore $DEVICE.

> for example:
>  - /proc/bus/usb not mounted
>  - /dev/bus/usb is present
>  - what should be in DEVICE ?
> 
> currently I have a situation with (k)ubuntu dapper / udev 079
> in this case: my application gets called, but with DEVICE pointing
> to /proc/bus/usb/... and that does not exist.

Sure, it didn't make sense in the first place to add an absolute path to
the kernel code.

> Sure, I can add magic code to my application. But before doing so
> I would first like to know if there is a consensus what should be
> in DEVICE and whos job it is to set it properly / handle alternative
> locations. so, what is the strategy on this?

Ignore $DEVICE and $INTERFACE entirely and use the values provided by
the kernel event and the sysfs device pointed to by $DEVPATH.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: DEVICE and usb strategy

[Andreas Jellinghaus]

Am Montag, 20. März 2006 02:00 schrieb Kay Sievers:
> Ignore $DEVICE.

...

> Ignore $DEVICE and $INTERFACE entirely and use the values provided by
> the kernel event and the sysfs device pointed to by $DEVPATH.

sorry, that doesn't work. udevmonitor tells me $DEVPATH is always something
that might exist in /sys/ namespace. but I need a device file, something I can
open and use with ioctl() to do my work. 

after all why should I be interested in those lower level values, as udev 
already does all the work mapping that to a device file name? I'm
only interested in the result: the device name, and of course which
hardware I'm dealing with, so I can start the right driver.

the RUN setting in udev rules: can I only specify my script, or can I use
that setting to pass a parameter to the script, too? if so I could live
without the hardware info and simply the info I need as parameter.

Andreas


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel