Re: hotplug arch. and apps

["Ken Hahn" <kenh@micro-solutions.com>]

What happens when there are two different packages that want the permissions
set different ways?  Which one wins? (the one with the last script)

Also, in a related issue, if you are going to do things like launch an
application when a device is added
(http://jphoto.sourceforge.net/?selected=sync) what happens when both gphoto
and jPhoto decide to launch when a device is added?

A centralized userspace library could keep this from occuring.
(not to mention abstract the interface.. I believe that alsa does something
like this).
Also I think it would provide a single point of entry for security worries
(instead of 10 million startup scripts).

One of the more annoying things in (older versions of) windows was the
cd-player starting up on the insertion of an audio CD.  Especially if you
had another cd-player active. (given these are media changes, but how far
away from device changes are media changes?)

It seems like there are two problems here:
1. The driver side (getting modules loaded/firmware loaded) when a device is
added.  It sounds like this side has been pretty well hashed out here, and
just needs to be coded completely.

2. Application notification/access to new device (permisssions on the device
file)
(and if you abstract this thought, is "mount" an application.. thus a simple
automounter)  Would media change fit here as well?

And why do we have like 10 million files in this directory?  Wouldn't it
make sense to think about this similarly to the way that cron works?  Both
handle launching things upon events?  One main file (or dirs for each class
of device (bus?)).
For comparison, Apache started out with multiple config files, and
eventually merged them together.

Just some randon thoughts and problems (maybe I'm crazy),


Ken Hahn

----- Original Message -----
From: "Scott Cuyle Fritzinger" <scottf@med.unr.edu>
To: <linux-hotplug-devel@lists.sourceforge.net>
Sent: Thursday, November 15, 2001 2:38 PM
Subject: hotplug arch. and apps


>
> Hey hotplug developers! My name is Scott Fritzinger, a developer with the
> gPhoto project (www.gphoto.org)
>
> In pushing out our newest version (2.0), we are coming up with ideas as to
> how to make digital cameras truly "plug and play" (when the user plugs in
> the camera, it's ready to use). We have come up with the following
> solution:
>
> Using a hotplug script (/etc/hotplug/usb/camera), we either set the
> ownership of the device (/proc/bus/usb/001/003 for example) to that of the
> locally logged in user in the case of a non-mass-storage camera, or we
> mount the mass-storage camera to /camera0 and set ownership again to the
> locally logged in user. this alleviates all the problems with permissions,
> and make the camera ready to use right away.
>
> the base of this is of course a hotplug script. there is a catch though:
> how does hotplug know which cameras gphoto (or other applications)
> support? we can easily go through and append the ID's to
> /etc/hotplug/usb.handmap|usb.usermap, but what about when gphoto is
> updated with a new camera list? we'd have to go back through find out
> which entries are there, and then add new ones. and removing an ID would
> be a bit tough too.
>
> I've come up with an idea that would make this REALLY easy to do, and it
> is only slightly different than what hotplug currently does. instead of
> just relying on usb.handmap or usb.usermap, why not create a directory
> /etc/hotplug/usb.map/ and place files in there that contain the ID's for
> the supported devices? the hotplug agent can open each file, look for ID's
> and then run the corresponding scripts.
>
> like, you can place all the HID device "lines" in /etc/hotplug/usb.map/hid
>
> in our (gphoto's) case, we can place everything in
> /etc/hotplug/usb.map/camera for all known (still) camera ID's. This will
> be a VERY generic file, not gphoto specific at all, but rather supportive
> of all apps out there. this file will cause the agent to run the
> /etc/hotplug/usb/camera script, which will then mount (usb mass storage)
> or set permissions on the device.
>
> this design allows for other applications that implement user-land drivers
> via libusb to set up proper permissions on the device when it is plugged
> in.
>
> is it possible alter the usb agent to work in this way? the downside would
> be disk hits for each file in /etc/hotplug/usb.map/* (a little slower),
> but the flexibility is that each application can EASILY update the devices
> it supports by just placing a file in there instead of having to search
> through a single file and replace (usb.handmap).
>
> ideas? thoughts?
>
> Thanks for reading! :)
>
> -=Scott
>
>
> _______________________________________________
> 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
>


_______________________________________________
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