From: Michael Hamilton <michael@actrix.gen.nz>
To: linux-hotplug@vger.kernel.org
Subject: Re: usb-mount (hotplug + desktop hooks)
Date: Wed, 13 Nov 2002 08:55:31 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-103717801318254@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103558971618973@msgid-missing>
While these busted devices are a bit of a pain, I don't like the
idea of saying device-X can't be supported, or that more than
one of device-X can't be supported. Especially when it operates
quite well on other operating systems.
If we want these bad-devices to work, I don't think there is any
other alternative than to provide a range of generic mount points
in addition to well identified ones.
Providing unknown devices stay on the same generic mount-points
for the duration of their presence, I don't think this approach
will be much harder to understand than the similar situation that
arises when you have to sort through a pile of floppies.
This is especially true if the desktop provides some kind of
visual indication that devices have appeared and disappeared.
For example, my scripted K-desktop solution immediately mounts
the device and changes the associated icon
( http://users.actrix.co.nz/michael/usbmount.html ).
On Tue, 12 Nov 2002 04:39, Gary_Lerhaupt@Dell.com wrote:
> Well, my flashcard reader seems to have a good USB GUID that is consistent
> in at least 2 different systems I've plugged it into. However, it has a
> bad scsi_unique_id of "1F00". So, in its case, the --usb-guid would seem
> to have worth.
>
> As far as devices that aren't consistently unique, devlabel can already
> handle this in the way that you would like (albeit, as long as you don't
> plug in at the same time both USB storage devices made by the same vendor
> but with bad scsi_unique_ids). Just add a generic symlink for that type of
> device like /dev/genericusb and regardless of which you plug-in, it will
> get mapped to that symlink. Perhaps, I could add a --force to allow the
> user to connect 2 devices with the same ID at the same time. I'd be
> worried that an unknowing user might hurt himself with this, though.
>
-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
_______________________________________________
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:[~2002-11-13 8:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-25 23:46 usb-mount (hotplug + desktop hooks) David Brownell
2002-10-26 9:35 ` Oliver Neukum
2002-10-28 21:52 ` Gary_Lerhaupt
2002-11-02 23:32 ` Michael Hamilton
2002-11-04 16:38 ` Gary_Lerhaupt
2002-11-05 9:46 ` Michael Hamilton
2002-11-06 4:23 ` Ajay
2002-11-06 9:21 ` Michael Hamilton
2002-11-06 15:53 ` Gary_Lerhaupt
2002-11-07 5:03 ` Michael Hamilton
2002-11-07 16:05 ` Gary_Lerhaupt
2002-11-11 8:11 ` Michael Hamilton
2002-11-11 15:39 ` Gary_Lerhaupt
2002-11-13 8:55 ` Michael Hamilton [this message]
2002-11-21 20:30 ` David Brownell
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-103717801318254@msgid-missing \
--to=michael@actrix.gen.nz \
--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.