Alan Cox <[EMAIL PROTECTED]> wrote:
> > And I can get devfsd to run it for me when I press the hotsync button
> > by
> > adding this line to /etc/devfsd.conf:
> > REGISTER usb/tty/1 EXECUTE sudo -u mcelrath
>~mcelrath/bin/visor-sync
> >
> > With these two things I can now hotsync simply by pressing the hotsync
> > button.
>
> Very nice indeed. So is devfsd enough to avoid writing another daemon
> and sending it change messages. At least if we expand the info passed
> a little ?
Not sure what you mean by "info passed". But since there is no info
about what /dev/usb/tty/1 actually *is*, then yes it would be useful to
get more info. I believe these numbers (/dev/usb/tty/*) are allocated
sequentially, so there's no guarantee that /dev/usb/tty/1 is my visor
(it could be another serial device, if I had one).
Adding hooks to devfsd to identify a device by vendor/product id would
be very useful. Alternatively, one could parse /proc/bus/usb/devices to
determine if the newly registered device is the one I care about. After
looking over /proc/bus/usb/devices (and
Documentation/usb/proc_usb_info.txt), it doesn't seem possible to derive
the name of the /dev entry allocated to a particular device reported in
/proc/bus/usb/devices. How about something adding something like the
following for devfsd:
DEVICE [name] [driver] [vendor id] [product id]
REGISTER [name] ACTION [args...]
where name is an arbitrary name for your device, so a real entry would
look like:
DEVICE Visor usb-serial 082d 0100
REGISTER Visor EXECUTE sudo -u mcelrath ~mcelrath/bin/visor-sync $devname
where $devname is the name of the /dev entry allocated for the device
(/dev/usb/tty/1).
I don't know how hard this info (vendor/product) is to get, nor how to
identify devices in general (USB uses vendor/product, but what about
PCI? SCSI?). But one might envision using this for all kinds of
hot-swappable devices. (auto-mount USB/SCSI hot-swappable storage
devices, fill my Diamond rio with new songs when I connect it to USB,
etc...)
The drawback, of course, is that you have to disable devfsd to get it to
*not* execute the action. For instance if I want to transfer something
new to my visor. But this is best dealt with by modifying my scripts,
or enhancing pilot-link's ability to hotsync, not in devfsd.
-- Bob
Bob McElrath ([EMAIL PROTECTED])
Univ. of Wisconsin at Madison, Department of Physics
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
