David Berg wrote:
On 3/8/06, Florian Kulzer <florian@molphys.leidenuniv.nl> wrote:David Berg wrote:I'm trying to automount my digital camera (mass storage) when it is connected. I have udev scripts to give me a /dev/camera symlink which appears to be working, and created a map in hotplug to call a script called photodl which seems to be getting called. The problem is that photodl is called before the device is created from udev.
[...]
How can I ensure that photodl is run after the device is created?I think the most reliable way is to use the PROGRAM key in your udev rule for the device. The following is an example for a PCMCIA network card: KERNEL=="eth*", SYSFS{address}=="xx:xx:xx:xx:xx:xx", NAME="wlan0", PROGRAM="/path/to/your/script" (all on the same line) /path/to/your/script should point to your script. It will be called whenever the device is created or removed. In the script you can check the $ACTION environmental variable ("add" or "remove") to know which event occurred. The manpage of udev has more details.I was under the impression that udev's sole purpose was to name /dev entries. And that hotplug is the apropriate place for calling scripts that will use that device. I'm still foggy on how some of these systems fit together. Does it matter? Looking at the hotplug scripts it would appear that scripts could be called from hotplug, udev, or hal. Which is most appropriate.
As far as I know, udev replaces hotplug. As you point out, udev's main
purpose is to generate the device entries in /dev as needed, but it also
incorporates the functionality of hotplug. I had the impression that
this was done because udev cannot really coexist with hotplug: When udev
is installed hotplug is removed from the system, and you are asked to
purge its configuration files. This lead me to believe that it is best
to go "100% udev" for all device configuration and plug-in scripting.
However, there are probably many different ways to achieve what you want
to do. Since your hotplug script is not called at the right moment it
seems to me that the next logical thing to try is the PROGRAM key in the
udev rule.
Regards,
Florian