linux-kernel - Re: [PATCH v1] scsi: Don't select SCSI_PROC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.21.1906220920320.180@nippy.intranet>
Date:   Sat, 22 Jun 2019 09:50:24 +1000 (AEST)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>
cc:     Douglas Gilbert <dgilbert@...erlog.com>,
        Bart Van Assche <bvanassche@....org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Martin Petersen <martin.petersen@...cle.com>,
        SCSI <linux-scsi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v1] scsi: Don't select SCSI_PROC_FS by default

On Fri, 21 Jun 2019, Marc Gonzalez wrote:

> On 21/06/2019 01:43, Finn Thain wrote:
> 
> > On Thu, 20 Jun 2019, Marc Gonzalez wrote:
> > 
> >> How likely is it that distro kernels would *not* enable CHR_DEV_SG? 
> >> (Distros tend to enable everything, and then some.)
> > 
> > How likely is it that embedded developers would *not* disable 
> > CHR_DEV_SG? They tend to disable everything, and then enable only what 
> > they need.
> 
> I don't see where you're going with this line of reasoning?
> 

Exactly. This sort of reasoning goes nowhere.

> Below is my current (as of next-20190612) defconfig.
> 
> Notice the options marked as "not set". These are options that are 
> enabled by default (and which I've disabled).
> 
> Everyone thinks "their" option is critical (and it is, *to them*) but, 
> in fact, few really are -- universally. 

The relevant policy is documented in 
Documentation/kbuild/kconfig-language.txt.

If there are useful generalizations about the choice of defaults for 
Kconfig symbols (or changing those defaults) that are not documented then 
they probably should be.

--