Messages in this thread Patch in this message | | | Subject | Re: [PATCH v1] scsi: Don't select SCSI_PROC_FS by default | From | Marc Gonzalez <> | Date | Wed, 19 Jun 2019 11:42:44 +0200 |
| |
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.
| |