[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c121430b1b5c8f5816b2b42b9178d00889260c90.camel@redhat.com>
Date: Fri, 08 Apr 2022 15:31:35 -0400
From: "Ewan D. Milne" <emilne@...hat.com>
To: John Garry <john.garry@...wei.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Alim Akhtar <alim.akhtar@...sung.com>,
Avri Altman <avri.altman@....com>,
Doug Gilbert <dgilbert@...erlog.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: james.smart@...adcom.com
Subject: Re: [PATCH 1/4] scsi: core: constify pointer to scsi_host_template
On Fri, 2022-04-08 at 13:57 +0100, John Garry wrote:
> On 08/04/2022 13:32, Krzysztof Kozlowski wrote:
> > On 08/04/2022 14:14, John Garry wrote:
> > > On 08/04/2022 11:30, Krzysztof Kozlowski wrote:
> > > > Several pointers to 'struct scsi_host_template' do not modify it, so
> > > > made them const for safety.
> > > >
> > > Is this standard practice? What is so special here?
> > This is standard practice and there is nothing special here. Pointers to
> > const are preferred because:
> > 1. They add safety if data is actually const. This is not yet the case,
> > but scsi_host_template allocation could be made const with some effort.
This seems unlikely, because some drivers, e.g. vmw_pvscsi and scsi_debug,
modify the scsi_host_template based on things like module parameters.
>
> To me this seems better, but I think that some drivers might modify
> their scsi_host_template (so not possible)
Several drivers modify scsi_host_template, e.g. .can_queue, .cmd_per_lun
There is also code in lpfc_create_port() that initializes a scsi_host_template
that is embedded in the lpfc_hba struct. I don't think it gets modified after
scsi_add_host() but it seems like driver maintainers might expect to be able
to do so, in general.
-Ewan
>
> > 2. The more const variables, the easier function contents and its impact
> > is to understand. This is actually the biggest benefit when dealing with
> > code touching different structures.
> >
> > In general, constifying is a common practice everywhere in the kernel.
>
> Thanks,
> John
>
Powered by blists - more mailing lists