* Re: possible change to usb.agent
2002-01-14 2:58 possible change to usb.agent Robert Anderson
@ 2002-01-14 19:17 ` David Brownell
2002-01-14 20:29 ` Robert Anderson
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: David Brownell @ 2002-01-14 19:17 UTC (permalink / raw)
To: linux-hotplug
> I used the jPhoto example, except where they used "usb.handmap" I used
> "usb.usermap". It seemed like the comments indicated it should be in
> the "usb.usermap" section to me, perhaps I misunderstood the comments?
That was a bug in the jPhoto "hotsync" example, which is
now fixed. (Thanks for reporting that!) "usermap" is correct.
Given that, I don't think there's a bug. When you load a kernel
module "foo", if there's a script /etc/hotplug/usb/foo it will also
be run. You shouldn't need a "usermap" entry in addition to
a kernel module ... just name the script after the module.
- 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: possible change to usb.agent
2002-01-14 2:58 possible change to usb.agent Robert Anderson
2002-01-14 19:17 ` David Brownell
@ 2002-01-14 20:29 ` Robert Anderson
2002-01-14 22:33 ` David Brownell
2002-01-15 14:43 ` Robert Anderson
3 siblings, 0 replies; 5+ messages in thread
From: Robert Anderson @ 2002-01-14 20:29 UTC (permalink / raw)
To: linux-hotplug
>Date: Mon, 14 Jan 2002 11:17:38 -0800
>From: David Brownell <david-b@pacbell.net>
>X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>Content-type: text/plain; charset=iso-8859-1
>X-Priority: 3
>X-MSMail-priority: Normal
>
>> I used the jPhoto example, except where they used "usb.handmap" I used
>> "usb.usermap". It seemed like the comments indicated it should be in
>> the "usb.usermap" section to me, perhaps I misunderstood the comments?
>
>That was a bug in the jPhoto "hotsync" example, which is
>now fixed. (Thanks for reporting that!) "usermap" is correct.
>
>Given that, I don't think there's a bug. When you load a kernel
>module "foo", if there's a script /etc/hotplug/usb/foo it will also
>be run. You shouldn't need a "usermap" entry in addition to
>a kernel module ... just name the script after the module.
>
>- Dave
Thanks for getting back to me so quickly.
Obviously you know what you're talking about, and it indeed works
great if I simply link my script in as "/etc/hotplug/usb/usb-storage".
Just to be safe I'm put in a test to exit if the $PRODUCT not equal to
'4cb/100/100'.
I can see this approach works great now, but I do wonder what happens
when I get an rpm that installs scripts for my MP3 player, Camera, and
external harddrive. I thought that was the idea behind the
"usb.usermap" file and all the matching options. The way I had
changed it the device driver would load as well as anything matching
in the usb.usermap file. It allowed individual and multiple scripts
per device.
Just adding my 2 cents. Feel free to ignore it, I'm very happy it
works and is a lot easier than I had originally thought. Keep up the
great work.
--------------------------------------------------------------
Robert E. Anderson email: rea@sr.unh.edu
Systems Programmer phone: (603) 862-3489
UNH Research Computing Center fax: (603) 862-1761
--------------------------------------------------------------
_______________________________________________
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: possible change to usb.agent
2002-01-14 2:58 possible change to usb.agent Robert Anderson
2002-01-14 19:17 ` David Brownell
2002-01-14 20:29 ` Robert Anderson
@ 2002-01-14 22:33 ` David Brownell
2002-01-15 14:43 ` Robert Anderson
3 siblings, 0 replies; 5+ messages in thread
From: David Brownell @ 2002-01-14 22:33 UTC (permalink / raw)
To: linux-hotplug
> Obviously you know what you're talking about, and it indeed works
> great if I simply link my script in as "/etc/hotplug/usb/usb-storage".
> Just to be safe I'm put in a test to exit if the $PRODUCT not equal to
> '4cb/100/100'.
It might be more easily extended if that's "case $PRODUCT in ...",
which I do in some other cases (firmware downloading). FWIW, I
think it's fair to say that SCSI hotplugging will be evolving a bunch
in the 2.5 tree ... and that such handling may well belong there,
rather than at the USB level!
> I can see this approach works great now, but I do wonder what happens
> when I get an rpm that installs scripts for my MP3 player, Camera, and
> external harddrive. I thought that was the idea behind the
> "usb.usermap" file and all the matching options.
No, the original intent was to support user mode drivers ("usermap").
With as few match options as practical -- since options create support
problems/costs. (Options lead to confusion ... ;)
Could you clarify why you'd expect those different kinds of usb-storage
device to get treated differently? I suspect I know why -- and it'll boil
down to wanting SCSI hotplug to have access to more information
in order to mount cameras under something like /mnt/camera/N and
MP3 players under /mnt/mp3/N, and handle CD/DVD burners in a
correspondingly intelligent way.
> The way I had
> changed it the device driver would load as well as anything matching
> in the usb.usermap file. It allowed individual and multiple scripts
> per device.
I think the current scheme also allows that, but doesn't try to standardize
any of it. Most of the cases I can imagine where a standard approach
would be needed feel to me like cases where higher level hotplug tools
(printer, scanner/sane, scsi, etc) should handle the problem. Given that,
I'm reluctant to encourage USB-level solutions, only to replace them when
the more capable solutions appear.
- 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: possible change to usb.agent
2002-01-14 2:58 possible change to usb.agent Robert Anderson
` (2 preceding siblings ...)
2002-01-14 22:33 ` David Brownell
@ 2002-01-15 14:43 ` Robert Anderson
3 siblings, 0 replies; 5+ messages in thread
From: Robert Anderson @ 2002-01-15 14:43 UTC (permalink / raw)
To: linux-hotplug
>Date: Mon, 14 Jan 2002 14:33:58 -0800
>From: David Brownell <david-b@pacbell.net>
>Cc: linux-hotplug-devel@lists.sourceforge.net
>X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>Content-type: text/plain; charset=iso-8859-1
>X-Priority: 3
>X-MSMail-priority: Normal
>> I can see this approach works great now, but I do wonder what happens
>> when I get an rpm that installs scripts for my MP3 player, Camera, and
>> external harddrive. I thought that was the idea behind the
>> "usb.usermap" file and all the matching options.
>
>No, the original intent was to support user mode drivers ("usermap").
>With as few match options as practical -- since options create support
>problems/costs. (Options lead to confusion ... ;)
Actually once I understood what those files did I thought it was an
extreemly cleaver idea. After the first few hours debuging and
following the code paths I ended up seeing how all the matching was
being done and was able to write the line I wanted for my Fuji camera.
It would have worked great except for the fact that my camera is
already using your code to install it's usb-storage driver, so it was
ignoring my usermap lines. Which is how I ended up here to begin with.
>Could you clarify why you'd expect those different kinds of usb-storage
>device to get treated differently? I suspect I know why -- and it'll boil
>down to wanting SCSI hotplug to have access to more information
>in order to mount cameras under something like /mnt/camera/N and
>MP3 players under /mnt/mp3/N, and handle CD/DVD burners in a
>correspondingly intelligent way.
SCSI hotplugging could handle many of the issues I was thinking of. I
also see how future drivers could be created that somehow block my
usermap scripts from working.
For an example that I'll document for you within the week. Take the
Canon A20 camera. It's not recognized by any of your drivers. I know
that ghoto2 can talk with it. I can configure an A20 script using
usb.usermap to match it's two main identifiers and pull all the photos
off using gphoto2. My script would work fine until somebody writes a
real driver for that device. So after I upgrade and the new drivers
are available, my old A20 script would no longer work. I then need to
track down what the new driver is and rename my /etc/hotplug/usb/A20
script to match the new driver (I should also clean out the
usb.usermap at the same time as it would then be unused and
misleading).
I'm very happy with how your code works and the support you're giving
it! My current intent is to donate some documented example code to
get two different cameras working. I think having more exmaples would
have helped me know your code quicker than all the debuging code I
went through. I want to give back something for all the hard work
you've done and I can easily document a few examples for you to use as
you wish.
>> The way I had
>> changed it the device driver would load as well as anything matching
>> in the usb.usermap file. It allowed individual and multiple scripts
>> per device.
>
>I think the current scheme also allows that, but doesn't try to standardize
>any of it. Most of the cases I can imagine where a standard approach
>would be needed feel to me like cases where higher level hotplug tools
>(printer, scanner/sane, scsi, etc) should handle the problem. Given that,
>I'm reluctant to encourage USB-level solutions, only to replace them when
>the more capable solutions appear.
>
>- Dave
Since in my A20 example above I'm using your code for nothing more
than a hook to autorun another script, I can see how far off on a
tangent this can lead. Obviously you can't solve all these problems
at your one level, I just wanted to bring another view of this into
the light. From my point of view what I need to do can change
depending on if a driver has or hasn't been developed yet. What I may
have considered a really specific match on my hardware gets ignored by
something that could be very generic, but exists in a higher tier of
mapfile.
I'll try to document two or three examples for you. One of the
reasons I didn't use a "case $PRODUCT in" was that if I only used an
"if [ $PRODUCT = X]" syntax you could just append more products onto
the same file, even have multiple scripts fire during the coarse of a
single script.
--------------------------------------------------------------
Robert E. Anderson email: rea@sr.unh.edu
Systems Programmer phone: (603) 862-3489
UNH Research Computing Center fax: (603) 862-1761
--------------------------------------------------------------
_______________________________________________
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
^ permalink raw reply [flat|nested] 5+ messages in thread