Re: hotplug arch. and apps

[Greg KH <greg@kroah.com>]

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