public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: 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: Mon, 17 Jun 2002 07:19:52 +0200	[thread overview]
Message-ID: <200206170719.52136.oliver@neukum.name> (raw)
In-Reply-To: <200206162314.g5GNEYf03058@localhost.localdomain>

Am Montag, 17. Juni 2002 01:14 schrieb James Bottomley:
> 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.

These may be an exception. You usually want to get drivers involved
even if only for synchronisation. Failing to do so has already let to
problems with usb storage.

> > 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

That is the point. The driver knows best what kind of devices it works on.
You can forget about the whole identification method business, if you
go for the driver. In case of usb storage and firewire that data is already
sitting there ready for taking. I suspect the same for fibrechannel.

	Regards
		Oliver


  reply	other threads:[~2002-06-17  5:19 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
2002-06-17  5:19           ` Oliver Neukum [this message]
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=200206170719.52136.oliver@neukum.name \
    --to=oliver@neukum.name \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=James.Bottomley@steeleye.com \
    --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