From: James Bottomley <James.Bottomley@steeleye.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
linux-scsi@vger.kernel.org
Subject: Re: Warning: about not setting max_sectors
Date: Tue, 10 Dec 2002 08:47:50 -0600 [thread overview]
Message-ID: <200212101447.gBAElpJ01949@localhost.localdomain> (raw)
In-Reply-To: Message from Christoph Hellwig <hch@infradead.org> of "Tue, 10 Dec 2002 13:23:48 GMT." <20021210132348.A31628@infradead.org>
hch@infradead.org said:
> I added this intentionally. The default is set in scsi_register_host
> which is an obsolete interface. This warning reminds driver writers
> to set the value explicitly, with scsi_add_host & friends they won't
> get a default anymore.
I don't think that's the correct behaviour. The parameter is labelled as
optional (and clearly should be for drivers that have no hard transfer limit).
The blk_queue_max_sectors() clearly should be initialised with the device in
mind. We have this limit coming at us from two directions: the driver (if it
imposes such a limit) and the device (e.g. a SCSI-1 device only does read 6
and thus 256 is the maximum etc.)
we should probably take the lowest of the scsi-1 minimum and the HBA if it
exists in scsi_initialize_queue and readjust it when we've decided on the
capabilities of the device.
In any event, moving the zero check for shpnt->max_sectors to
scsi_initialize_queue would fix the loss of scsi_add_host, wouldn't it?
James
next prev parent reply other threads:[~2002-12-10 14:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-09 14:55 Warning: about not setting max_sectors James Bottomley
2002-12-10 13:23 ` Christoph Hellwig
2002-12-10 14:13 ` GOTO Masanori
2002-12-10 14:47 ` James Bottomley [this message]
2002-12-11 10:57 ` Christoph Hellwig
2002-12-11 14:37 ` James Bottomley
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=200212101447.gBAElpJ01949@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=hch@infradead.org \
--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 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.