From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: John Garry <john.garry@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>,
Logan Gunthorpe <logang@deltatee.com>,
<linux-scsi@vger.kernel.org>, <linux-block@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Intel SCU Linux support <intel-linux-scu@intel.com>,
Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Jens Axboe <axboe@kernel.dk>, Jeff Moyer <jmoyer@redhat.com>,
chenxiang <chenxiang66@hisilicon.com>
Subject: Re: [PATCH] scsi: isci: initialize shost fully before calling scsi_add_host()
Date: Fri, 11 Jan 2019 21:34:19 -0500 [thread overview]
Message-ID: <yq1lg3qy578.fsf@oracle.com> (raw)
In-Reply-To: <8d96b40d-fc83-9218-9479-3de423594ddb@huawei.com> (John Garry's message of "Thu, 10 Jan 2019 09:11:44 +0000")
John,
> So how about just drop these APIs and let the user set the shost
> protection parameters directly, like other shost parameters,
The protection interfaces here obviously predate the block layer
allocation changes that made this particular issue pop up.
> which should make it a bit clearer when these should be set,
> i.e. before scsi_add_host()?
In general, I am not so keen on the somewhat messy intersection between
the host parameters and the host template. The static host templates
made lots of sense in the days of Seagate ST01 and fixed hardware
capabilities. But reality is that most modern controllers have to query
firmware interfaces to figure out what their actual capabilities are.
So in this case I think that accessor functions are actually better
because they allow us to print a big fat warning when you twiddle
something you shouldn't post-initialization. So that's something I think
we could--and should--improve.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2019-01-12 2:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 20:50 [PATCH] scsi: isci: initialize shost fully before calling scsi_add_host() Logan Gunthorpe
2019-01-08 21:25 ` Jeff Moyer
2019-01-08 21:30 ` Jens Axboe
2019-01-09 3:29 ` Martin K. Petersen
2019-01-09 18:41 ` Christoph Hellwig
2019-01-10 9:11 ` John Garry
2019-01-12 2:34 ` Martin K. Petersen [this message]
2019-01-14 12:10 ` John Garry
2019-01-16 2:54 ` Martin K. Petersen
2019-01-16 14:44 ` John Garry
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=yq1lg3qy578.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=artur.paszkiewicz@intel.com \
--cc=axboe@kernel.dk \
--cc=chenxiang66@hisilicon.com \
--cc=hch@lst.de \
--cc=intel-linux-scu@intel.com \
--cc=jejb@linux.ibm.com \
--cc=jmoyer@redhat.com \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=logang@deltatee.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).