On 19/06/2019 16:34, Douglas Gilbert wrote: > On 2019-06-19 5:42 a.m., Marc Gonzalez wrote: > >> 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. > > Yes, but (see below) ... > > Example of use of /proc/scsi/scsi [...] > Now looking at /proc/scsi/device_info [...] > > IMO unless there is a replacement for /proc/scsi/device_info > then your patch should not go ahead . If it does, any reasonable > distro should override it. > > That is a black (or quirks) list that can be added to by writing an > entry to /proc/scsi/device_info . So if a user has a device that needs > one of those quirks defined to stop their system locking up when a > device of that type is plugged in, and the distro or some app (say, > that needs that device) knows about that, then it would be sad if > /proc/scsi/device_info was missing due to the changed default that is > being proposed. You've made it clear that SCSI_PROC_FS is important for several classes of hardware. You worry that changing the Kconfig default would force distro maintainers (we are talking about Debian/Redhat/Suse/etc right?) to actually turn the feature on, instead of relying on the "default y" behavior (as they have done in the past). How likely is it that distro kernels would *not* enable CHR_DEV_SG? (Distros tend to enable everything, and then some.) CHR_DEV_SG is enabled in the default configs for i386 and x86_64: $ git grep CHR_DEV_SG arch/x86/configs/ arch/x86/configs/i386_defconfig:CONFIG_CHR_DEV_SG=y arch/x86/configs/x86_64_defconfig:CONFIG_CHR_DEV_SG=y => As soon as CHR_DEV_SG is enabled, SCSI_PROC_FS is also enabled. (I work on smaller systems where we do use /proc occasionally, but we don't enable CHR_DEV_SG or SCSI_PROC_FS.) I think we just need to find a reasonable condition for enabling SCSI_PROC_FS by default on "your" sytems, and not on "mine" ;-) Regards.
