From: James Bottomley <James.Bottomley@steeleye.com>
To: David Brownell <david-b@pacbell.net>
Cc: Andries.Brouwer@cwi.nl, garloff@suse.de,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
sancho@dauskardt.de, linux-usb-devel@lists.sourceforge.net,
linux1394-devel@lists.sourceforge.net, dougg@torque.net
Subject: Re: [linux-usb-devel] Re: /proc/scsi/map
Date: Sun, 16 Jun 2002 12:25:06 -0500 [thread overview]
Message-ID: <200206161725.g5GHP6S23020@localhost.localdomain> (raw)
In-Reply-To: Message from David Brownell <david-b@pacbell.net> of "Sun, 16 Jun 2002 10:05:49 PDT." <3D0CC56D.9050805@pacbell.net>
Since we already have a huge long list of different ways to identify different
devices, I don't think coding any one or even a set of such methods into the
kernel would satisfy everyone.
What about a different approach:
We already (nearly) have the scsimon patches to do hot plug events on SCSI
devices incorporated. Any identification could be done from the scsi device
hotplug script (i.e. if you see it's USB, get the GID, if it's enterprise
storage get the WWN, try the filesystem UUID etc). Then all the hotplug
script does is plug this device into some type of volume idenfication scheme
like /dev/volume/<name>.
Any application needing to always know where the device is would refer to it
by name, and since there's no prescription at all about what the <name> is,
you could even alias horribly unfriendly things like the WWN to more palatable
names using a user specified translation table.
This implementation doesn't even depend on SCSI, so it could potentially be
used by any subsystem (IDE, block devices).
The only component that doesn't exist is the configurable /dev/volume piece.
Since the name would be a property of the device node, it probably makes sense
to place this into the new driverfs somehow.
James
next prev parent reply other threads:[~2002-06-16 17:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-15 21:54 /proc/scsi/map Andries.Brouwer
2002-06-15 22:27 ` /proc/scsi/map Douglas Gilbert
2002-06-15 22:40 ` /proc/scsi/map Sancho Dauskardt
2002-06-16 20:36 ` /proc/scsi/map Kurt Garloff
2002-06-15 22:28 ` /proc/scsi/map Sancho Dauskardt
2002-06-16 17:05 ` [linux-usb-devel] /proc/scsi/map David Brownell
2002-06-16 17:25 ` James Bottomley [this message]
2002-06-16 20:54 ` Oliver Neukum
2002-06-16 22:02 ` James Bottomley
2002-06-16 22:38 ` Oliver Neukum
2002-06-16 23:14 ` James Bottomley
2002-06-17 5:19 ` Oliver Neukum
2002-06-17 14:54 ` James Bottomley
2002-06-17 16:09 ` Patrick Mansfield
2002-06-17 16:42 ` James Bottomley
2002-06-17 19:07 ` Patrick Mansfield
2002-06-17 20:25 ` James Bottomley
2002-06-17 16:53 ` David Brownell
2002-06-17 17:15 ` 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=200206161725.g5GHP6S23020@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=david-b@pacbell.net \
--cc=dougg@torque.net \
--cc=garloff@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=sancho@dauskardt.de \
/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
all inboxes | Powered by JetHome®