hotplug arch. and apps

hotplug arch. and apps

[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:

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

Re: hotplug arch. and apps

[Stephen Williams]

scottf@med.unr.edu said:
> 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.

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.


-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Scott Cuyle Fritzinger]

> scottf@med.unr.edu said:
> > 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.
> 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Stephen Williams]

scottf@med.unr.edu 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.
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Greg KH]

On Thu, Nov 15, 2001 at 12:38:03PM -0800, Scott Cuyle Fritzinger wrote:
> 
> 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.

Sounds great.

> 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.

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.

> like, you can place all the HID device "lines" in /etc/hotplug/usb.map/hid

These should be covered by the modules.usbmap file.

> 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. 

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?

> 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.

> 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.)

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[David Brownell]

> 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?  :)


> 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 :)


> in our (gphoto's) case, we can place everything in
> /etc/hotplug/usb.map/camera for 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.


> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Scott Cuyle Fritzinger]

On Thu, 15 Nov 2001, Greg KH wrote:
> On Thu, Nov 15, 2001 at 12:38:03PM -0800, Scott Cuyle Fritzinger wrote:

> > 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.

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.

> > like, you can place all the HID device "lines" in /etc/hotplug/usb.map/hid
> These 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...

> > /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. 
> 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?

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. 

> 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.

> > 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.)
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Scott Cuyle Fritzinger]

> > 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.

> > in our (gphoto's) case, we can place everything in
> > /etc/hotplug/usb.map/camera for 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Johannes Erdfelt]

On Thu, Nov 15, 2001, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 15, 2001 at 03:39:58PM -0800, Scott Cuyle Fritzinger wrote:
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Greg KH]

On Thu, Nov 15, 2001 at 03:39:58PM -0800, Scott Cuyle Fritzinger wrote:
> 
> 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.

> 
> > > like, you can place all the HID device "lines" in /etc/hotplug/usb.map/hid
> > These 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 :)

> > 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?
> 
> 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.

> 
> > 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.
> 
> > > 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.)
> > > 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? 

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.

> if a USB mass storage camera is plugged in, and the kernel loads the
> appropriate modules, is hotplug called at all?

Yes.

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[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


----- Original Message ----- 
From: "Johannes Erdfelt" <johannes@erdfelt.com>
To: "Greg KH" <greg@kroah.com>
Cc: <linux-hotplug-devel@lists.sourceforge.net>
Sent: Thursday, November 15, 2001 5:42 PM
Subject: Re: hotplug arch. and apps


> On Thu, Nov 15, 2001, Greg KH <greg@kroah.com> wrote:
> > On Thu, Nov 15, 2001 at 03:39:58PM -0800, Scott Cuyle Fritzinger wrote:
> > > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[Johannes Erdfelt]

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

On Thu, Nov 15, 2001, David Brownell <david-b@pacbell.net> wrote:
> 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" <johannes@erdfelt.com>
> To: "Greg KH" <greg@kroah.com>
> Cc: <linux-hotplug-devel@lists.sourceforge.net>
> Sent: Thursday, November 15, 2001 5:42 PM
> Subject: Re: hotplug arch. and apps
> 
> 
> > On Thu, Nov 15, 2001, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Nov 15, 2001 at 03:39:58PM -0800, Scott Cuyle Fritzinger wrote:
> > > > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug arch. and apps

[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)

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

Re: hotplug arch. and apps

[Scott Cuyle Fritzinger]

(warning: here comes a brain dump.)

On Fri, 16 Nov 2001, Ken Hahn wrote:
> 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
> 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..

> 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

> 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


> > 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