Re: [PATCH v1] scsi: Don't select SCSI_PROC_FS by default

[Marc Gonzalez]

On 18/06/2019 17:31, Douglas Gilbert wrote:

> On 2019-06-18 3:29 a.m., Marc Gonzalez wrote:
> 
>> Please note that I am _in no way_ suggesting that we remove any code.
>>
>> I just think it might be time to stop forcing CONFIG_SCSI_PROC_FS into
>> every config, and instead require one to explicitly request the aging
>> feature (which makes CONFIG_SCSI_PROC_FS show up in a defconfig).
>>
>> Maybe we could add CONFIG_SCSI_PROC_FS to arch/x86/configs/foo ?
>> (For which foo? In a separate patch or squashed with this one?)
> 
> Since current sg driver usage seems to depend more on SCSI_PROC_FS
> being "y" than other parts of the SCSI subsystem then if
> SCSI_PROC_FS is to default to "n" in the future then a new
> CONFIG_SG_PROC_FS variable could be added.
> 
> If CONFIG_CHR_DEV_SG is "*" or "m" then default CONFIG_SG_PROC_FS
> to "y"; if CONFIG_SCSI_PROC_FS is "y" then default CONFIG_SG_PROC_FS
> to "y"; else default CONFIG_SG_PROC_FS to "n". Obviously the
> sg driver would need to be changed to use CONFIG_SG_PROC_FS instead
> of CONFIG_SCSI_PROC_FS .

I like your idea, and I think it might even be made slightly simpler.

I assume sg3_utils requires CHR_DEV_SG. Is it the case?

If so, we would just need to enable SCSI_PROC_FS when CHR_DEV_SG is enabled.

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 73bce9b6d037..642ca0e7d363 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -54,14 +54,12 @@ config SCSI_NETLINK
 config SCSI_PROC_FS
 	bool "legacy /proc/scsi/ support"
 	depends on SCSI && PROC_FS
-	default y
+	default CHR_DEV_SG
 	---help---
 	  This option enables support for the various files in
 	  /proc/scsi.  In Linux 2.6 this has been superseded by
 	  files in sysfs but many legacy applications rely on this.
 
-	  If unsure say Y.
-
 comment "SCSI support type (disk, tape, CD-ROM)"
 	depends on SCSI
 

Would that work for you?
I checked that SCSI_PROC_FS=y whether CHR_DEV_SG=y or m
I can spin a v2, with a blurb about how sg3_utils relies on SCSI_PROC_FS.

> Does that defeat the whole purpose of your proposal or could it be
> seen as a partial step in that direction? What is the motivation
> for this proposal?

The rationale was just to look for "special-purpose" options that are
enabled by default, and change the default wherever possible, as a
matter of uniformity.

> BTW We still have the non-sg related 'cat /proc/scsi/scsi' usage
> and 'cat /proc/scsi/device_info'. And I believe the latter one is
> writable even though its permissions say otherwise.

Any relation between SG and BSG?

Regards.