linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Anderson <rea@q.sr.unh.edu>
To: linux-hotplug@vger.kernel.org
Subject: Re: possible change to usb.agent
Date: Tue, 15 Jan 2002 14:43:18 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-101110584217769@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101097712222027@msgid-missing>


>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

      parent reply	other threads:[~2002-01-15 14:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

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-101110584217769@msgid-missing \
    --to=rea@q.sr.unh.edu \
    --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).