From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug arch. and apps
Date: Thu, 15 Nov 2001 22:02:58 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-100586177803722@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-100585666514602@msgid-missing>
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
next prev parent reply other threads:[~2001-11-15 22:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-15 20:38 hotplug arch. and apps Scott Cuyle Fritzinger
2001-11-15 20:48 ` Stephen Williams
2001-11-15 21:45 ` Scott Cuyle Fritzinger
2001-11-15 21:51 ` Stephen Williams
2001-11-15 22:02 ` Greg KH [this message]
2001-11-15 22:51 ` David Brownell
2001-11-15 23:39 ` Scott Cuyle Fritzinger
2001-11-15 23:44 ` Scott Cuyle Fritzinger
2001-11-16 1:42 ` Johannes Erdfelt
2001-11-16 2:26 ` Greg KH
2001-11-16 3:42 ` David Brownell
2001-11-16 4:06 ` Johannes Erdfelt
2001-11-16 16:11 ` Ken Hahn
2001-11-16 19:45 ` Scott Cuyle Fritzinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-100586177803722@msgid-missing \
--to=greg@kroah.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).