From: James Bottomley <James.Bottomley@steeleye.com>
To: Oliver Neukum <oliver@neukum.name>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
David Brownell <david-b@pacbell.net>,
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 17:02:33 -0500 [thread overview]
Message-ID: <200206162202.g5GM2XT02750@localhost.localdomain> (raw)
In-Reply-To: Message from Oliver Neukum <oliver@neukum.name> of "Sun, 16 Jun 2002 22:54:42 +0200." <200206162254.42323.oliver@neukum.name>
oliver@neukum.name said:
> How would you find out what a device is ? If the kernel has to supply
> the information anyway, you could just as well pass all information to
> the script or devfs.
But the kernel doesn't know this globally unique identifier information today,
that's what the discussion is about.
The essence of the problem is that there's no one method that can get a unique
identifier for every SCSI device (even though almost every device possesses
one in one form or another). So you have to implement a collection of ad hoc
methods depending on what the device actually is.
The idea behind using hotplug to solve the problem is that with scsimon, a
hotplug insertion event is generated for every SCSI device as it is added.
The script is provided with the information the kernel knows (host, channel,
pun lun, model and vendor inquiry strings---see www.torque.net/scsimon.html
for details). The hotplug script then does the remaining processing to
extract the ID from the device (by ioctls, sending down SCSI commands etc.)
and then binds it into the /dev/volume nodes using the identifier it
determines.
The result is that however you move the device around (between controllers or
even change its id), it will always show up as its unique /dev/volume name.
The key philosophy is that the code to make the policy decision for assigning
a unique name isn't cluttering up the kernel, it's in user land where it can
be easily customised. Once scsimon is part of the kernel, we need no other
kernel changes at all to implement this, since /dev/volume could just be done
with symbolic links (although having the kernel know the name is useful).
James
next prev parent reply other threads:[~2002-06-16 22:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3D0CC56D.9050805@pacbell.net>
2002-06-16 17:25 ` [linux-usb-devel] Re: /proc/scsi/map James Bottomley
2002-06-16 20:54 ` Oliver Neukum
2002-06-16 22:02 ` James Bottomley [this message]
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
[not found] <UTC200206152154.g5FLsCI23053.aeb@smtp.cwi.nl>
2002-06-16 17:05 ` 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=200206162202.g5GM2XT02750@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=oliver@neukum.name \
--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