Messages in this thread | | | Date | Tue, 12 Apr 2022 08:57:39 +0100 | Subject | Re: [PATCH 1/4] scsi: core: constify pointer to scsi_host_template | From | John Garry <> |
| |
On 08/04/2022 20:31, Ewan D. Milne wrote: > 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. >
The standard flow is:
shost = scsi_host_alloc(sht, )
// modify shost, like shost->cmd_per_lun = 5;
scsi_add_host(shost)
Is there some reason for which those two drivers can't follow that?
>> >> 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. >
Even so, I don't see why other drivers cannot declare their scsi_host_template as const. C would have no problem with sht not be being const for this:
struct Scsi_Host *scsi_host_alloc(const struct scsi_host_template *sht, )
thanks, John
| |