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 18:14:33 -0500 [thread overview]
Message-ID: <200206162314.g5GNEYf03058@localhost.localdomain> (raw)
In-Reply-To: Message from Oliver Neukum <oliver@neukum.name> of "Mon, 17 Jun 2002 00:38:51 +0200." <200206170038.51403.oliver@neukum.name>
oliver@neukum.name said:
> But the drivers already know, or would have to be taught to know about
> it. Somewhence that information has to come. You cannot avoid that
> effort.
Not necessarily: consider the SCSI WWN, which is supported by most modern SCSI
devices. The driver never probes for or asks for this. Nowhere in the
current SCSI code do we ask for this. However user level commands (like
sg_inq) can formulate the 0x83 page inquiry to get this and return the output.
This works today with the current driver.
> That is wrong. You'd need a common method to determine device type and
> several methods of passing guid. You are better off in implementing
> one common way of getting at that information, which shouldn't be too
> hard, as all the generic layer would have to do is pass up that
> information.
but the complexity is in the "common method to determine device type and
several methods of passing guid". Even for a simple SCSI disk, there's no one
universal way of getting a unique id (let alone when we add the usb devices
masquerading as scsi disks into the mix). That will lead us to scanning a
list of inquiry strings to see what the disk is and determine what globally
unique ID it supports. Since we have to implement a lookup table just to
determine how to get the unqiue id, it's far better off being done outside the
kernel.
James
next prev parent reply other threads:[~2002-06-16 23:14 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
2002-06-16 22:38 ` Oliver Neukum
2002-06-16 23:14 ` James Bottomley [this message]
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=200206162314.g5GNEYf03058@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