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 >
