On 25/04/2022 15:04, John Garry wrote:
>
>> For example scsi_proc_hostdir_rm(): 'present' and 'proc_dir' members.
>> Where should they be stored? Should they be moved to the Scsi_Host?
>>
>
> I don't think scsi_Host is appropriate as this is per-scsi host
> template, unless you see a way to do it that way. Alternatively we could
> keep a separate list of registered sht, like this:
>
> struct sht_proc_dir {
> int cnt;
> struct list_head list;
> struct proc_dir_entry *proc_dir;
> struct scsi_host_template *sht;
> };
> static LIST_HEAD(sht_proc_dir_list);
Hi everyone,
It took me some time to get back to this topic. I moved the proc_dir out
of SHT, how John proposed. Patches do not look that bad:
The commit:
https://github.com/krzk/linux/commit/157eb2ee8867afbae9dac3836e4c0bedb542e5c1
Branch:
https://github.com/krzk/linux/commits/n/qcom-ufs-opp-cleanups-v2
However this does not solve the problem. The SHT has "module" which gets
incremented/decremented. Exactly like in case of other drivers
(driver->owner).
I started moving the SHT->module to a new field scsi_host->owner and
trying to use the parent's driver (so PCI, USB) owner.
I am not sure if it is correct approach, so before implementing such big
change affecting multiple subsystems (USB, ATA, SCSI) - can you share
ideas/opinion?
The Work-in-Progress looks like this (last commit):
https://github.com/krzk/linux/commit/17609caecd53df20f631703ea084a70e7735b5d7
Best regards,
Krzysztof
