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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · [email protected] said:
Using a hotplug script (
/etc/hotplug/usb/camera), we either set the ownership of the device (/proc/bus/usb/001/003for 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.
I had a similar problem with a PROM programmer I built, and tackled it with the fxload that is now part of the hotplug CVS repository. Basically, I wrote a little script, called by a user map, that uses fxload to set the mode of the device to 0666 and create a link to the /proc/ device in /var/run so that an application can just poll for gflash.lnk.
I also added REMOVER script support to remove the link when the device is disconnected.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 5 lines · [email protected] said:
Using a hotplug script (
/etc/hotplug/usb/camera), we either set the ownership of the device (/proc/bus/usb/001/003for 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.
Quoted 8 lines
I had a similar problem with a PROM programmer I built, and tackled it with the fxload that is now part of the hotplug CVS repository. Basically, I wrote a little script, called by a user map, that uses fxload to set the mode of the device to 0666 and create a link to the
/proc/device in/var/runso that an application can just poll for gflash.lnk.
I also added REMOVER script support to remove the link when the device is disconnected.
but you placed the USB ID for the PROM programmer in the handmap right? or did you do this some other way...
what i'd like to see is an easy way to update the handmap/usermap ID definitions so that when a user updates gphoto, for example, we can easily insert new device ID's for which the hotplug usb agent should recognize and run the appropriate camera script. split the maps out into several files in /etc/hotplug/usb.map/* and have the agent open each looking for a match for the device, instead of just looking through the usb.handmap and usb.usermap files.
-=Scott
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · [email protected] said:
but you placed the USB ID for the PROM programmer in the handmap right? or did you do this some other way...
You're right. I only addressed a portion of your message.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Scott Cuyle Fritzinger
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:
Quoted 6 lines
Using a hotplug script (
/etc/hotplug/usb/camera), we either set the ownership of the device (/proc/bus/usb/001/003for 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.
Sounds great.
Quoted 8 lines
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.
Quoted 6 lines
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.
This needs to play nice with the automated /lib/modules/<kernel_version>/modules.usbmap files too (these are automatically built by depmod so the hotplug scripts know what kernel drivers match what devices.
But I suppose if no match is found in the kernel driver list, searching a directory is a good idea.
Quoted 1 line
like, you can place all the HID device "lines" in
/etc/hotplug/usb.map/hid
These should be covered by the modules.usbmap file.
Quoted 6 lines
in our (gphoto's) case, we can place everything in
/etc/hotplug/usb.map/camerafor 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/camerascript, which will then mount (usb mass storage) or set permissions on the device.
What would you expect the /etc/hotplug/usb.map/camera file to look like? Would it have all usb product/vendor ids that gphoto2 works with, or would there be single file for ever product/vendor pair?
Quoted 3 lines
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.
That is a great idea, and as more USB devices are supported by user space programs (like gphoto) instead of kernel drivers, this will become more important.
Quoted 5 lines
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).
Don't worrry about the speed hit, the flexibility is much more important (I don't think a user minds that a device takes an extra second or so to initialize everything when it is plugged in.)
Quoted 1 line
ideas? thoughts?
I think it's a great idea, and am interested in further implementation details.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
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.
Sounds good to me. Got a patch against CVS? :)
Quoted 1 line
like, you can place all the HID device "lines" in
/etc/hotplug/usb.map/hid
Input system hotplugging will finish someday ... those tweaks should not be needed forever :)
Quoted 2 lines
in our (gphoto's) case, we can place everything in
/etc/hotplug/usb.map/camerafor all known (still) camera ID's.
I'd rather have that be specific to gPhoto2. Best not to have gPhoto2 take over such responsibilities for other programs, that'd just shift all the problems into gPhoto2.
Quoted 2 lines
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),
Only for devices that aren't already handled by the kernel.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Greg KH
Quoted 6 lines · Scott Cuyle Fritzinger
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.
Quoted 4 lines
This needs to play nice with the automated /lib/modules/<kernel_version>/modules.usbmap files too (these are automatically built by depmod so the hotplug scripts know what kernel drivers match what devices.
yup! from what i've read, it seems like the modules.usbmap has 'first dibs' on any device, and then the usb.handmap is referenced if nothing matches there.
Quoted 2 lines
Quoted 1 line
like, you can place all the HID device "lines" in
/etc/hotplug/usb.map/hidThese should be covered by the modules.usbmap file.
ah. ok.
without trying to rock the boat too much, is there a reason why it isn't just moved to hotplug instead? :P is it that not everyone uses hotplug? or that the kernel doesn't want to depend on external apps? i'm ignorant as to this issue...
Quoted 8 lines
Quoted 5 lines
/etc/hotplug/usb.map/camerafor 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/camerascript, which will then mount (usb mass storage) or set permissions on the device.What would you expect the
/etc/hotplug/usb.map/camerafile to look like? Would it have all usb product/vendor ids that gphoto2 works with, or would there be single file for ever product/vendor pair?
it would contain all camera product/vendor ID's that gphoto or any other application supports. basically a repository of USB id's for still cameras.
Quoted 3 lines
That is a great idea, and as more USB devices are supported by user space programs (like gphoto) instead of kernel drivers, this will become more important.
very cool. i think doing things this way would make handling USB devices a little more 'hands-free' because it lets applications (via hotplug scripts) handle the nitty-gritty (permissions, ownership, mounting, etc...) and give the end-user a nicer experience.
Quoted 11 lines
Quoted 5 lines
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).Don't worrry about the speed hit, the flexibility is much more important (I don't think a user minds that a device takes an extra second or so to initialize everything when it is plugged in.)
Quoted 1 line
ideas? thoughts?
I think it's a great idea, and am interested in further implementation details.
here's another thing:
still cameras come in 3 main 'flavors' now:
- proprietary protocols
- Picture Transfer Protocol (PTP)
- USB Mass Storage
the first 2 can use some simple permission/ownership script action that sets owner=localuser, no problems... we have a script doing this already.
the last one we'd like to mount automatically to /camera0 or something when it is plugged in. Now, the USB Mass Storage driver is loaded automatically via modules.usbmap (storage class driver), but is hotplug called after that?
if a USB mass storage camera is plugged in, and the kernel loads the appropriate modules, is hotplug called at all?
if hotplug isn't called, then there isn't any automounting. is there a way to get hotplug to be called regardless, not to load subsequent drivers, but rather handle permissions/ownership/mounting/etc... like, a Mass storage camera is plugged, the modules are loaded, and then hotplug is called which will in turn call the camera script, which will see that it is a mass storage camera and mount it to /camera0.
we could play around with fstab, but that would be a PITA. it'd be nice to have that depend on a hotplug script that is easily updateable and quite dynamic in nature.
this may very well break other things that i'm not aware of, so any input on this idea is really needed :P
Thanks!
-=Scott
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 5 lines
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.Sounds good to me. Got a patch against CVS? :)
i'll see what i can hack up this weekend. :) i don't have a mass-storage camera, so i can't test that. i can test moving to a multi-file map directory though.
we already have a hotplug script that handles the permissions, so i'll start with that base.
Quoted 5 lines
Quoted 2 lines
in our (gphoto's) case, we can place everything in
/etc/hotplug/usb.map/camerafor all known (still) camera ID's.I'd rather have that be specific to gPhoto2. Best not to have gPhoto2 take over such responsibilities for other programs, that'd just shift all the problems into gPhoto2.
ah. understood. then perhaps a /etc/hotplug/usb.map/gphoto map, and /etc/hotplug/usb/gphoto script to handle things.
-=Scott
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Greg KH
Quoted 3 lines · Scott Cuyle Fritzinger
yup! from what i've read, it seems like the modules.usbmap has 'first dibs' on any device, and then the usb.handmap is referenced if nothing matches there.
Exactly.
This is something I'd like to fix at some point. We haven't solved the problem of devices with multiple alternate settings that can be handled by multiple drivers.
Like the uss720 chips which have a native mode and a USB printer class alternate setting.
We should prefer to use the native mode in that case.
JE
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Scott Cuyle Fritzinger
yup! from what i've read, it seems like the modules.usbmap has 'first dibs' on any device, and then the usb.handmap is referenced if nothing matches there.
Exactly.
Quoted 10 lines
Quoted 3 lines
Quoted 2 lines
like, you can place all the HID device "lines" in
/etc/hotplug/usb.map/hidThese should be covered by the modules.usbmap file.
ah. ok.
without trying to rock the boat too much, is there a reason why it isn't just moved to hotplug instead? :P is it that not everyone uses hotplug? or that the kernel doesn't want to depend on external apps? i'm ignorant as to this issue...
Using the automatic generated tables is the best way to keep up with new drivers, and what devices they support. It keeps people from manually having to upgrade their hotplug table package, or editing files by hand. We want to automate this as much as possible. Look at /etc/pcmcia/config for an example of what we don't want to end up like :)
Quoted 7 lines
Quoted 3 lines
What would you expect the
/etc/hotplug/usb.map/camerafile to look like? Would it have all usb product/vendor ids that gphoto2 works with, or would there be single file for ever product/vendor pair?it would contain all camera product/vendor ID's that gphoto or any other application supports. basically a repository of USB id's for still cameras.
What happens when two files contain the same product/vendor id? Should the hotplug scripts just stop when it finds the first match? A single file for every program is nice, it lets updates for that single program be easier.
Quoted 29 lines
Quoted 4 lines
That is a great idea, and as more USB devices are supported by user space programs (like gphoto) instead of kernel drivers, this will become more important.
very cool. i think doing things this way would make handling USB devices a little more 'hands-free' because it lets applications (via hotplug scripts) handle the nitty-gritty (permissions, ownership, mounting, etc...) and give the end-user a nicer experience.
Quoted 11 lines
Quoted 5 lines
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).Don't worrry about the speed hit, the flexibility is much more important (I don't think a user minds that a device takes an extra second or so to initialize everything when it is plugged in.)
Quoted 1 line
ideas? thoughts?
I think it's a great idea, and am interested in further implementation details.
here's another thing:
still cameras come in 3 main 'flavors' now:
- proprietary protocols
- Picture Transfer Protocol (PTP)
- USB Mass Storage
Quoted 7 lines
the first 2 can use some simple permission/ownership script action that sets owner=localuser, no problems... we have a script doing this already.
the last one we'd like to mount automatically to /camera0 or something when it is plugged in. Now, the USB Mass Storage driver is loaded automatically via modules.usbmap (storage class driver), but is hotplug called after that?
Yes it is. But it's a "USB device added" event. It might be nice if we have a "filesystem added" kernel event to /sbin/hotplug so that programs can realize that something new is out there to scan, without having to constantly parse /proc/partitions or some such file.
One problem with mass storage devices, is that it might be tough to tell the difference from a filesystem on a USB floppy from that of one on a USB Camera.
Quoted 2 lines
if a USB mass storage camera is plugged in, and the kernel loads the appropriate modules, is hotplug called at all?
Yes.
Quoted 6 lines
if hotplug isn't called, then there isn't any automounting. is there a way to get hotplug to be called regardless, not to load subsequent drivers, but rather handle permissions/ownership/mounting/etc... like, a Mass storage camera is plugged, the modules are loaded, and then hotplug is called which will in turn call the camera script, which will see that it is a mass storage camera and mount it to /camera0.
Take a look at the autofs package. I think it might be what you want.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Johannes, what sort of policy criteria would you suggest for choosing one driver versus another?
The "usbmodules" command is able to use richer inputs to its policy. Right now what it does is exactly mimic the policy that the kernel uses.
Seems we'd need to start recording (preferably in the kernel and then exported) things like "prefer uss720 to printer".
So far my thought in this area has been that the kernel needs to stay simple, and this sort of logic can be done in userland given suitable binding/unbinding/rebinding hooks in the kernel.
- Dave
----- Original Message -----
From: "Johannes Erdfelt" <[email protected]>
To: "Greg KH" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 15, 2001 5:42 PM
Subject: Re: hotplug arch. and apps
Quoted 12 lines · Greg KH
Quoted 6 lines · Scott Cuyle Fritzinger
Quoted 3 lines
yup! from what i've read, it seems like the modules.usbmap has 'first dibs' on any device, and then the usb.handmap is referenced if nothing matches there.
Exactly.
This is something I'd like to fix at some point. We haven't solved the problem of devices with multiple alternate settings that can be handled by multiple drivers.
Quoted 8 lines
Like the uss720 chips which have a native mode and a USB printer class alternate setting.
We should prefer to use the native mode in that case.
JE
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
My original devfs based patch used a priority number. Basically the the biggest priority got elected to be the driver to be loaded and bound to the interface.
It was arbitrary and less than perfect.
The only thing I can think of now is to favor vendor specific alternate settings over class alternate settings. I'm not sure if this is the best assumption to make however.
JE
Quoted 18 lines · David Brownell
Johannes, what sort of policy criteria would you suggest for choosing one driver versus another?
The "usbmodules" command is able to use richer inputs to its policy. Right now what it does is exactly mimic the policy that the kernel uses.
Seems we'd need to start recording (preferably in the kernel and then exported) things like "prefer uss720 to printer".
So far my thought in this area has been that the kernel needs to stay simple, and this sort of logic can be done in userland given suitable binding/unbinding/rebinding hooks in the kernel.
- Dave
Quoted 30 lines
----- Original Message -----
From: "Johannes Erdfelt" <[email protected]>
To: "Greg KH" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 15, 2001 5:42 PM
Subject: Re: hotplug arch. and appsQuoted 20 lines · Greg KH
Quoted 6 lines · Scott Cuyle Fritzinger
Quoted 3 lines
yup! from what i've read, it seems like the modules.usbmap has 'first dibs' on any device, and then the usb.handmap is referenced if nothing matches there.
Exactly.
This is something I'd like to fix at some point. We haven't solved the problem of devices with multiple alternate settings that can be handled by multiple drivers.
Like the uss720 chips which have a native mode and a USB printer class alternate setting.
We should prefer to use the native mode in that case.
JE
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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" <[email protected]>
To: <[email protected]>
Sent: Thursday, November 15, 2001 2:38 PM
Subject: hotplug arch. and apps
Quoted 54 lines
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/003for 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/hidin our (gphoto's) case, we can place everything in
/etc/hotplug/usb.map/camerafor 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/camerascript, 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! :)
Quoted 8 lines
-=Scott
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
(warning: here comes a brain dump.)
Quoted 2 lines · Ken Hahn
What happens when there are two different packages that want the permissions set different ways? Which one wins? (the one with the last script)
this is a problem. two applications can 'want' to handle the device, but only 1 will win.
to fix this, hotplug/usb.agent can set a default/standard security policy such that any device plugged in is owned by the local user (for example). then jphoto and gphoto both know what to expect, and what their respective scripts can do without stepping on each other's toe. all matching scripts are run. this way, no one has to 'win' in order for both to work.
non-mass storage camera plugged in
Quoted 4 lines
hotplug runs usb.agent
usb.agent sets perms/ownership and calls all matching scripts
jphoto script syncs to disk
gphoto script syncs to disk (too!)
- the 'load' of setting permissions and doing stuff with the device is taken away from the scripts and put into usb.agent
- another plus is: consider the jphoto sync script. usb.agent can pass in a $USER variable, and jphoto can sync it directly to the user's home directory instead of just to /root
- if the user doesn't want both scripts called, they remove one. hotplug will set perms/owner, then call all scripts that match the device ID.
taking a step back, really, the local user is the one who 'owns' the device. consider a computer lab where someone brings in a camera and plugs it, they should have perms to use it right away.
there are cases when someone shouldn't be have ownership/perms on the device (think USB drive that is used to hold system software, perhaps mounted to /opt or /usr/local). there can be 'exceptions' for devices that shouldn't have the ownership/perms set to the local user. how to define these is something i haven't thought about yet. maybe usb.agent references a file that contains USB VID/PID/SerialNumber and if something matches, perms are left as root only... i don't know... :P
what if the user logs out and another logs in? they'll either need to replug the device, or something will need to force the hotplug script to run again for a new local login. that's the downside to this kind of policy and something that should be considered further..
Quoted 9 lines
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).
this would require some mods to the apps though. not MUCH of a problem. how would something like this work?
on startup, would the application 'register' itself and a corresponding script? or would it just register itself, with perhaps a user ID and the lib would take care of permissions/ownership? what about the case where we want to mount a mass-storage device that isn't mounted already? or does hotplug use this library in order to 'set up' the device?
if it is for use by an application, then does the application 'register' itself with the library? if this is the case, are any hotplug scripts run and when? if the hotplug scripts aren't run until an application 'registers', then what if i plug in a camera and just 'cd /camera0'. it isn't mounted because no application (gphoto) registered and therefore it isn't mounted automatically...
i think i'm asking too many detailed questions without knowing what the full idea behind it... has this been discussed on the list? sorry if he questions are a bit much... :P
Quoted 4 lines
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.
the kernel loader and hotplug scripts deal with this nicely.
-=Scott
Quoted 53 lines
Quoted 53 lines
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/003for 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/hidin our (gphoto's) case, we can place everything in
/etc/hotplug/usb.map/camerafor 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/camerascript, 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! :)
Quoted 9 lines
Quoted 8 lines
-=Scott
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel