linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Hamilton <michael@actrix.gen.nz>
To: linux-hotplug@vger.kernel.org
Subject: Re: usb-mount (hotplug + desktop hooks)
Date: Tue, 05 Nov 2002 09:46:00 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103648984527468@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103558971618973@msgid-missing>

Yes they are separate devices - They are two 128MB usb ram-drives.
But the same Neodeo chipset, with the same ID, and maybe the same
serial numbers, appears in other devices like card readers. 

Usb serials can be found in
  /proc/scsi/usb-storage*
and 
  /proc/bus/usb/devices
But I suspect there's a bug in the kernel that forms the entry in
/proc/bus/usb/devices because it doesn't always match the entry
in /proc/scsi/usb-storage* - but I haven't had a chance to look
into this further.

But USB serials seem to be pretty useless because they aren't enforced.
Here's a fragment of a response I received from the linux-usb-users list
that pretty much sums it up.  In particular, note the comment 
about serial numbers not being persistant - which is what triggered
my enquiries.

> From: "Randy.Dunlap" <rddunlap@osdl.org>
> X-X-Sender:  <rddunlap@dragon.pdx.osdl.net>
> To: Michael Hamilton <michael@gentoo.co.nz>
> Cc: <linux-usb-users@lists.sourceforge.net>
> Subject: Re: [Linux-usb-users] Auto mount/unmount: need explanation of serial numbers?
>
> Interesting.
>
> | 1. What part of the serial remains constant for the same device,
> |    if any?
>
> Not part of the USB spec.  This is device-specific behavior.
>
> | 2. Is the serial number the way to recognise the same device
> |    or am I barking up the wrong tree?
>
> The USB spec says that certain USB storage devices (like bulk-only)
> require a serial number and that it is unique for each
> idVendor/idProduct pair and at least 12 digits long.
> Unfortunately I don't see anything in the spec that requires the
> serial number to be persistent (unchanging), which would be
> desirable IMO.
>
> If I were attempting this, I too would have tried to use serial number,
> and eventually someone out there would have run into this problem.
> 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?
>
> -- 
> ~Randy

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.  The only way I found to clear this 
up is to unload the usb-storage module.  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

  parent reply	other threads:[~2002-11-05  9:46 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 [this message]
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
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-103648984527468@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 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).