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
