All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Luben Tuikov <luben_tuikov@adaptec.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
Date: Fri, 09 Sep 2005 18:25:03 -0500	[thread overview]
Message-ID: <1126308304.4799.45.camel@mulgrave> (raw)
In-Reply-To: <4321E51F.8040906@adaptec.com>

On Fri, 2005-09-09 at 15:40 -0400, Luben Tuikov wrote:
> +/**
> + * sas_do_lu_discovery -- Discover LUs of a SCSI device
> + * @dev: pointer to a domain device of interest

Aside from all the other problems, this one completely duplicates the
mid-layer infrastructure for handling devices with Logical Units.

> + * Discover logical units present in the SCSI device.  I'd like this
> + * to be moved to SCSI Core, but SCSI Core has no concept of a "SCSI
> + * device with a SCSI Target port".  A SCSI device with a SCSI Target
> + * port is a device which the _transport_ found, but other than that,
> + * the transport has little or _no_ knowledge about the device.
> + * Ideally, a LLDD would register a "SCSI device with a SCSI Target
> + * port" with SCSI Core and then SCSI Core would do LU discovery of
> + * that device.

That would be what scsi_scan_target() actually does.

> + * REPORT LUNS is mandatory.  If a device doesn't support it,
> + * it is broken and you should return it.  Nevertheless, we
> + * assume (optimistically) that the link hasn't been severed and
> + * that maybe we can get to the device anyhow.

That's a surprisingly optimistic statement from someone who claims to
have worked in SCSI for so long.  We have a huge list of heuristics for
devices that violate the standards in one way or another.  We already
have a flag for a SCSI3 device that doesn't respond correctly to
REPORT_LUNS ... and we have a few other reports of potentially more
suspect devices.

Now, if you did this properly and used the mid-layer infrastructure you
wouldn't have to worry about any of this.

> +static int sas_do_lu_discovery(struct domain_device *dev)

Please just handle targets ... scanning beyond targets is best handled
in generic code.

James



  parent reply	other threads:[~2005-09-09 23:26 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 19:40 [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) Luben Tuikov
2005-09-09 19:59 ` Nish Aravamudan
2005-09-09 20:11   ` Luben Tuikov
2005-09-09 23:25 ` James Bottomley [this message]
2005-09-10  2:44   ` Luben Tuikov
2005-09-10  5:39     ` Douglas Gilbert
2005-09-10 16:01     ` James Bottomley
2005-09-12 15:06       ` Luben Tuikov
2005-09-12 16:27         ` Patrick Mansfield
2005-09-12 20:08           ` Luben Tuikov
2005-09-13  9:05           ` Douglas Gilbert
2005-09-13 13:11             ` Luben Tuikov
2005-09-13 22:42             ` Patrick Mansfield
2005-09-14 12:28               ` Luben Tuikov
2005-09-14 17:13                 ` Patrick Mansfield
2005-09-14 17:17                   ` Luben Tuikov
2005-09-14 18:47               ` James Bottomley
2005-09-14 20:20                 ` Luben Tuikov
2005-09-12 17:52         ` James Bottomley
2005-09-12 20:31           ` Luben Tuikov
2005-09-12 21:23             ` James Bottomley
2005-09-13 12:49               ` Luben Tuikov
2005-09-13 15:54                 ` James Bottomley
2005-09-13 20:01                   ` Luben Tuikov
2005-09-11  9:46     ` Christoph Hellwig
2005-09-12  6:17       ` Douglas Gilbert
2005-09-12 14:57         ` James Bottomley
2005-09-12 16:45           ` Patrick Mansfield
2005-09-12 17:21             ` James Bottomley
2005-09-12 18:46               ` Patrick Mansfield
2005-09-13 19:22                 ` James Bottomley
2005-09-13 20:23                   ` Luben Tuikov
2005-09-13 20:36                     ` Matthew Wilcox
2005-09-13 21:02                       ` Luben Tuikov
2005-09-13 21:37                         ` Stefan Richter
2005-09-13 21:54                           ` Luben Tuikov
2005-09-13 22:25                         ` Patrick Mansfield
2005-09-14  5:22                           ` Sergey Panov
2005-09-14 16:28                             ` Patrick Mansfield
2005-09-14 12:13                           ` Luben Tuikov
2005-09-14  4:57                       ` Sergey Panov
2005-09-14 18:43                         ` James Bottomley
2005-09-14 20:17                           ` Luben Tuikov
2005-09-15  2:04                           ` Sergey Panov
2005-09-12 20:20               ` Luben Tuikov
2005-09-12 20:09             ` Luben Tuikov
2005-09-12 19:39           ` Luben Tuikov
2005-09-12 18:17         ` Luben Tuikov
2005-09-13 10:25         ` Christoph Hellwig
2005-09-13 12:47           ` Douglas Gilbert
2005-09-13 14:58             ` Luben Tuikov
2005-09-12 22:39       ` Luben Tuikov
  -- strict thread matches above, loose matches on Subject: below --
2005-09-12 19:04 James.Smart
2005-09-12 19:04 ` James.Smart
2005-09-12 19:29 ` Patrick Mansfield
2005-09-12 19:53 James.Smart
2005-09-12 19:53 ` James.Smart
2005-09-14  0:58 Ravi Anand
2005-09-14 17:46 Ravi Anand
2005-09-16  7:28 Andreas Herrmann

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=1126308304.4799.45.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luben_tuikov@adaptec.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.