Re: [PATCH 1/4] scsi: core: constify pointer to scsi_host_template

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-04-25 21:16, Bart Van Assche wrote:
On 4/25/22 06:04, John Garry wrote:
On 25/04/2022 10:22, Krzysztof Kozlowski 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);

void scsi_proc_hostdir_add(struct scsi_host_template *sht)
{
     struct sht_proc_dir *dir;

     if (!sht->show_info)
         return;

     mutex_lock(&global_host_template_mutex);
     list_for_each_entry(dir, &sht_proc_dir_list, list) {
         if (dir->sht == sht) {
             dir->cnt++;
             goto out;
         }
     }
     dir = kzalloc(sizeof(*dir), GFP_KERNEL);
     if (!dir)
         goto out;

     dir->proc_dir = proc_mkdir(sht->proc_name, proc_scsi);
     if (!dir->proc_dir) {
         printk(KERN_ERR "%s: proc_mkdir failed for %s\n",
                    __func__, sht->proc_name);
         kfree(dir);
         goto out;
     }

     dir->cnt++;
     list_add_tail(&dir->list, &sht_proc_dir_list);
out:
     mutex_unlock(&global_host_template_mutex);
}

How about removing scsi_proc_hostdir_add(), scsi_proc_hostdir_rm() and all other code that creates files or directories under /proc/scsi? There should be corresponding entries in sysfs for all /proc/scsi entries. Some tools in sg3_utils use that directory so sg3_utils will have to be updated.

... breaking this:

~$ cat /proc/scsi/scsi

Attached devices:

Host: scsi3 Channel: 00 Id: 00 Lun: 00

  Vendor: IBM-207x Model: HUSMM8020ASS20   Rev: J4B6

  Type:   Direct-Access                    ANSI  SCSI revision: 06

Host: scsi3 Channel: 00 Id: 01 Lun: 00

  Vendor: IBM-207x Model: HUSMM8020ASS20   Rev: J4B6

  Type:   Direct-Access                    ANSI  SCSI revision: 06

Host: scsi3 Channel: 00 Id: 02 Lun: 00

  Vendor: SEAGATE  Model: ST200FM0073      Rev: 0007

  Type:   Direct-Access                    ANSI  SCSI revision: 06
...

A deprecation notice would be helpful, then removal after a few kernel
cycles. Yes, lsscsi can give that output:

$ lsscsi -c

Attached devices:

Host: scsi2 Channel: 00 Target: 00 Lun: 00

  Vendor: SEAGATE  Model: ST200FM0073      Rev: 0007

  Type:   Direct-Access                    ANSI SCSI revision: 06

Host: scsi2 Channel: 00 Target: 01 Lun: 00

  Vendor: WDC      Model: WSH722020AL5204  Rev: C421

  Type:   Zoned Block                      ANSI SCSI revision: 07

Host: scsi2 Channel: 00 Target: 02 Lun: 00

  Vendor: Areca Te Model: ARC-802801.37.69 Rev: 0137

  Type:   Enclosure                        ANSI SCSI revision: 05
...

[Hmmm, in a different order.]

However no distribution that I'm aware of includes lsscsi in its installation.
[Most recent example: Ubuntu 22.04]
Linux is not alone ... in FreeBSD how do you list SCSI devices in your
system? Answer: as root you invoke 'camcontrol devlist', it's so obvious.

Perhaps the Linux kernel could have a deprecation process which uses inotify
or similar to notice accesses to /proc/scsi/scsi (say) and print out
a helpful response along the lines" "this is no longer supported, try using
the lsscsi utility".

Doug Gilbert






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux