From: Christoph Hellwig <hch@infradead.org>
To: Kurt Garloff <garloff@suse.de>,
Linux SCSI list <linux-scsi@vger.kernel.org>,
James Bottomley <James.Bottomley@steeleye.com>,
Andrew Morton <akpm@osdl.org>
Subject: Re: PATCH 2/5: scsi-scan-blist_replun
Date: Wed, 21 Apr 2004 16:14:12 +0100 [thread overview]
Message-ID: <20040421161412.B6793@infradead.org> (raw)
In-Reply-To: <20040421141234.GT28633@tpkurt.garloff.de>; from garloff@suse.de on Wed, Apr 21, 2004 at 04:12:34PM +0200
On Wed, Apr 21, 2004 at 04:12:34PM +0200, Kurt Garloff wrote:
>
> Cleanup/Feature
>
> Remove CONFIG_SCSI_REPORT_LUNS config option.
> Instead provide BLIST_NOREPORTLUN that can be passed as default_dev_flags
> (but also per device if needed).
> Provide BLIST_REPORTLUN2
Can we make this simply BLIST_REPORTLUN? I always have to think why the
2 is there until I guess this could mean only for scsi <= 2..
> -#ifdef CONFIG_SCSI_REPORT_LUNS
> /*
> * max_scsi_report_luns: the maximum number of LUNS that will be
> * returned from the REPORT LUNS command. 8 times this value must
> @@ -88,13 +87,12 @@ MODULE_PARM_DESC(max_luns,
> * in practice, the maximum number of LUNs suppored by any device
> * is about 16k.
> */
> -static unsigned int max_scsi_report_luns = 128;
> +static unsigned int max_scsi_report_luns = 511;
Hmm, where does this number come from?
> /*
> - * Only support SCSI-3 and up devices.
> - */
> - if (sdev->scsi_level < SCSI_3)
> + * Only support SCSI-3 and up devices if BLIST_NOREPORTLUN is not set.
> + * Also allow SCSI-2 if BLIST_REPORTLUN2 is set and host adapter does
> + * support more than 8 LUNs.
This comment and the nested if is a little confusing. Also why shouldn't
the arbitrary SCSI2 limit for BLIST_REPORTLUN2? I'm sure we won't find
SCSI1 devices supporting it, but there should not be any harm leaving out
that check - and doing so makes the logic much cleaner.
/*
* REPORT_LUN is used by default only for SCSI 3 devices (unless
* BLIST_NOREPORTLUN is set). For other devices BLIST_REPORTLUN
* enables it if the HBA does support more than 8 LUNs.
if (bflags & BLIST_NOREPORTLUN)
return 1;
if (sdev->scsi_level < 3 && sdev->host->max_lun <= 8 &&
!(bflags & BLIST_REPORTLUN2))
return 1;
Note that I'd prefer not to add BLIST_NOREPORTLUN if the discussing
about the LUN mapping comes to a useable consensus.
next prev parent reply other threads:[~2004-04-21 15:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-18 18:57 Patches for SCSI scanning Kurt Garloff
2004-04-18 23:16 ` James Bottomley
2004-04-20 11:54 ` Kurt Garloff
2004-04-20 12:04 ` Christoph Hellwig
2004-04-20 13:02 ` Kurt Garloff
2004-04-20 14:38 ` James Bottomley
2004-04-20 16:03 ` Kurt Garloff
2004-04-20 16:08 ` James Bottomley
2004-04-21 13:48 ` Kurt Garloff
2004-04-21 15:36 ` James Bottomley
2004-04-21 13:45 ` Kurt Garloff
2004-04-21 14:10 ` PATCH 1/5: scsi-scan-deprecate-forcelun Kurt Garloff
2004-04-21 14:12 ` PATCH 2/5: scsi-scan-blist_replun Kurt Garloff
2004-04-21 15:14 ` Christoph Hellwig [this message]
2004-04-21 15:30 ` Kurt Garloff
2004-04-21 16:03 ` Kurt Garloff
2004-04-21 14:13 ` PATCH 3/5: scsi-scan-no-offl-pq-notcon Kurt Garloff
2004-04-21 14:14 ` PATCH 4/5: scsi-scan-dont-att-pq-notcon Kurt Garloff
2004-04-21 15:02 ` Christoph Hellwig
2004-04-21 15:24 ` Kurt Garloff
2004-04-21 15:33 ` Mike Anderson
2004-04-21 15:33 ` Christoph Hellwig
2004-04-21 16:08 ` Kurt Garloff
2004-04-21 16:18 ` James Bottomley
2004-04-21 16:55 ` Patrick Mansfield
2004-04-21 22:51 ` Kurt Garloff
2004-04-22 20:39 ` Patrick Mansfield
2004-04-22 20:45 ` James Bottomley
2004-04-21 16:58 ` Kurt Garloff
2004-04-21 16:16 ` Kurt Garloff
2004-04-21 15:40 ` James Bottomley
2004-04-21 14:14 ` PATCH 5/5: scsi-scan-inq-timeout Kurt Garloff
2004-04-21 20:24 ` Patrick Mansfield
2004-04-21 22:48 ` Kurt Garloff
2004-04-21 23:49 ` Patrick Mansfield
2004-04-20 16:26 ` Patches for SCSI scanning Patrick Mansfield
2004-04-20 16:42 ` Kurt Garloff
2004-04-20 17:44 ` Patrick Mansfield
2004-04-21 13:52 ` Kurt Garloff
2004-04-20 10:24 ` Fabien Salvi
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=20040421161412.B6793@infradead.org \
--to=hch@infradead.org \
--cc=James.Bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=garloff@suse.de \
--cc=linux-scsi@vger.kernel.org \
/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