[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1lg3qy578.fsf@oracle.com>
Date: Fri, 11 Jan 2019 21:34:19 -0500
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: John Garry <john.garry@...wei.com>
Cc: Christoph Hellwig <hch@....de>,
Logan Gunthorpe <logang@...tatee.com>,
<linux-scsi@...r.kernel.org>, <linux-block@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
Intel SCU Linux support <intel-linux-scu@...el.com>,
Artur Paszkiewicz <artur.paszkiewicz@...el.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Jens Axboe <axboe@...nel.dk>, Jeff Moyer <jmoyer@...hat.com>,
chenxiang <chenxiang66@...ilicon.com>
Subject: Re: [PATCH] scsi: isci: initialize shost fully before calling scsi_add_host()
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
Powered by blists - more mailing lists