possible change to usb.agent

possible change to usb.agent

[Robert Anderson]

I've been trying to get a script to autorun when my USB Fuji 2800
camera is added to the system.  I could only get it to work by
changing the program flow in "usb.agent".  It seemed that
"usb.usermap" was only looked at if no other match was found?

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?

If I'm way off here please let me know so that I can conform to what
was expected.  I'm giving a user group talk on Monday evening 1/13/02,
and I'd like to be give out the correct information.

----------------------------------------------------------------------
I was using the following rpm on Redhat 7.2 and 7.1 systems:
----------------------------------------------------------------------

[root@anthill hotplug]# rpm -qi hotplug
Name        : hotplug                      Relocations: (not relocateable)
Version     : 2001_04_24                        Vendor: Red Hat, Inc.
Release     : 11                            Build Date: Mon 27 Aug 2001 12:41:30 PM EDT
Install date: Sun 13 Jan 2002 09:31:19 PM EST      Build Host: stripples.devel.redhat.com
Group       : System Environment/Kernel     Source RPM: hotplug-2001_04_24-11.src.rpm
Size        : 97618                            License: GPL
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://linux-hotplug.sourceforge.net/
Summary     : A helper application which loads modules for USB devices.
Description :
The term "hotplugging" refers to the dynamic reconfiguration performed
after a device has been attached to a running system. This package
contains the application which is called by the kernel when a USB
device is added; hotplug then loads the required modules for that
device.

----------------------------------------------------------------------
The line I added to /etc/hotplug/usb.usermap
----------------------------------------------------------------------

cam2hd 0x3 0x4cb 0x100 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

----------------------------------------------------------------------
The diff of my one line change to /etc/hotplug/usb.agent
----------------------------------------------------------------------

[root@anthill hotplug]# diff -c  usb.agent.orig usb.agent
*** usb.agent.orig      Sun Jan 13 21:31:38 2002
--- usb.agent   Sun Jan 13 21:31:58 2002
***************
*** 307,313 ****
      fi
  
      # some devices have user-mode drivers (no kernel module, but config)
!     if [ "$FOUND" = "false" -a -r $MAP_USERMAP ]; then
        MODPROBE=:
        load_drivers usb $MAP_USERMAP "$LABEL"
        if [ "$DRIVERS" != "" ]; then
--- 307,313 ----
      fi
  
      # some devices have user-mode drivers (no kernel module, but config)
!     if [ -r $MAP_USERMAP ]; then
        MODPROBE=:
        load_drivers usb $MAP_USERMAP "$LABEL"
        if [ "$DRIVERS" != "" ]; then
[root@anthill hotplug]# 


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

Re: possible change to usb.agent

[David Brownell]

> 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

Re: possible change to usb.agent

[Robert Anderson]

>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

Re: possible change to usb.agent

[David Brownell]

> 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

Re: possible change to usb.agent

[Robert Anderson]

>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