All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: possible change to usb.agent
Date: Mon, 14 Jan 2002 22:33:58 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-101104777331863@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101097712222027@msgid-missing>

> 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

  parent reply	other threads:[~2002-01-14 22:33 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 [this message]
2002-01-15 14:43 ` Robert Anderson

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-101104777331863@msgid-missing \
    --to=david-b@pacbell.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.