All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ajay <a_ajay_sr@yahoo.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: usb-mount (hotplug + desktop hooks)
Date: Wed, 06 Nov 2002 04:23:11 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103655665631661@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103558971618973@msgid-missing>

I've been thinking of a linux automount utility for
USB MSD compliant devices that works in conjunction
with hotplug. I basically read /proc/bus/usb/devices,
get the vid-pid-serial, read /proc/scsi/scsi to check
for SCSI devices, then read /proc/scsi/usb-storage-*/*
for the vid-pid-serial match (from the GUID). Now
since the serial match is vital for device
identification, this sort of shakes me up a bit.

> > The larger problem is that there are lots of USB
> storage devices
> > that don't have (or require) a serial number at
> all.  How are you
> > handling those?

AFAIK MSD Devices all need a serial number. Is that
right?

> Things get a little more confusing because, if a
> usb-device's serial
> changes when ever the device is unplugged and
> replugged, it will 
> march down the scsi bus.  For example, plug it in
> once and
> it appears as /dev/sda, unplug it and plug it in
> again and it will
> be /dev/sdb, then /dev/sdc, and so on. I suspect
> this is because 
> the usb-serial keeps changing.  

Again, AFAIK the serial can be changed only if the
Device firmware is flashed. Assuming a user will flash
it before plugging it in each time seems to be an
overkill.

> The only way I found
> to clear this 
> up is to unload the usb-storage module.

Also, the fact is that /dev/sda, etc. are only
'relative labels' - i.e. if you had plugged in a
device before the one you're using, _that_ would have
been /dev/sda and your device /dev/sdb, even if the
serial hasn't changed (this after unloading - loading
the usb-storage module). 

Thanks and regards
Ajay
--------------------------------
  I'm not
> sure if the kernel 
> can deal with this nicely - because, if it did, I
> think it would
> exhibit bad behaviour for devices that do have a
> constant serial.
> On the other hand, should a device hold onto
> /dev/sda a week after
> you unplugged it just because you haven't rebooted
> since - I guess
> the it should have a lease that times out.  
> 
> This is a messy business. I suspect the best that
> can be done 
> is to create a desktop folder where USB devices come
> and go.  
> Each device should named as meaningfully as possible
> and have 
> a tool-tip with as much info as can be retrieved
> about he 
> identity of the device (Manufacturer, Name, etc).
> But ultimately 
> the user must figure out which device is which by
> inspection.
> 
> Yeah - volume labels aren't likely - but if Linux
> becomes the
> the platform of choice, we can try and make it so.
> 
> I haven't had time to check out what 2.5 is up to in
> respect to
> the above issues - has anyone seen a good summary
> anywhere?
> 
> Michael
> 
> On Tue, 05 Nov 2002 05:38, Gary_Lerhaupt@Dell.com
> wrote:
> > Are these physically separate USB storage devices
> made by the same
> > manufacturer?  Or is this device more like a USB
> card reader and you are
> > having problems differentiating between the cards
> that you put into the
> > reader?  I have a feeling its the first case,
> which is unfortunate because
> > with a bad ID like "1f00" for both, devlabel won't
> work for you.  Or, at
> > least it would work for you if you only plugged in
> one at a time.
> >
> > If you do go with the one-at-a-time approach, then
> you could create a
> > symlink name to be shared by both like
> /dev/neodio_storage and then go
> > about automounting with /etc/fstab, etc.  However,
> this won't work for both
> > at the same time (as you've seen).
> >
> > I'm interested in the usb-serial idea, though.  
> Where are these kept? 
> > Even if they aren't implemented on many devices,
> I'd still like to add any
> > possible identifier to make devlabel work in more
> scenarios.  You also
> > mention a volume label, but with USB storage
> devices, this isn't likely.
> > Well, at least not on my smart card reader.
> > -Gary
> >
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact
> size!
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> 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 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
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-11-06  4:23 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 [this message]
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
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-103655665631661@msgid-missing \
    --to=a_ajay_sr@yahoo.com \
    --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.