linux-kernel - Re: [GIT PULL] platform-drivers-x86 for 4.15-1

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: <20171120171711.GA379@fury>
Date:   Mon, 20 Nov 2017 09:17:11 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Sat, Nov 18, 2017 at 12:09:10PM -0800, Linus Torvalds wrote:
> On Sat, Nov 18, 2017 at 10:37 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > So I note that you seem to use the same summary script that Darren used.
> 
> .. oh, and I note a *much* worse issue.
> 
> You add new drivers and then default them to "on".
> 
> THAT IS COMPLETELY UNACCEPTABLE.
> 
> I don't know why I have to say this every single merge window, but
> let's do it one more time:
> 
>   As a developer, you think _your_ driver or feature is the most
> important thing ever, and you have the hardware.
> 
>   AND ALMOST NOBODY ELSE CARES.
> 
> Read it and weep. Unless your hardware is completely ubiquitous, it
> damn well should not default to being defaulted everybody elses
> config.

Understood and agreed, this is especially true for our subsystem which
is full of .... platform .... specific drivers.

> 
> In particular, people who do "make oldconfig" clearly had a
> configuration _without_ your hardware and were happy with it, and want
> to keep it working. That's what "oldconfig" means.
> 
> You don't say "hey, let's enable this piece of hardware that you don't
> have anyway, just to waste your time and disk and memory".
> 
> So the things that merit "default y/m" are
> 
>  (a) you added a Kconfig option for something that used to always be
> built. Then it merits that "default y" exactly because "make
> oldconfig" should just work.
> 
>  (b) corollary of the above: if you add a new gatekeeping Kconfig
> option that hides/shows other Kconfig options (but doesn't generate
> any code of its own), it should be enabled by default, simply so that
> by default people will see those other options.
> 
>  (c) your driver itself defaults to off, but you then have sub-driver
> options for behavior or similar, where you can give sane defaults for
> people who _do_ have your hardware, and want the driver for it, and
> within those constraints the extended option makes sense
> 
>  (d) your piece of hardware or infrastructure really is something that
> everybody expects. If you have CONFIG_NET or CONFIG_BLOCK, you get to
> enable it by default.
> 
> But something like CONFIG_DELL_SMBIOS sure as hell does not merit
> being default on. Not even if you have enabled WMI.
> 
> EVERY SINGLE "default" line that got added by this branch was wrong.
> 
> Stop doing this. It's a serious violation of peoples expectations.
> When I do "make oldconfig", I don't want some new random hardware
> support.

The above looks like good Documentation/ material. A quick scan doesn't
find it, but I'll look more closely and prepare a patch adding it if
I don't find it.

I'll have a sidebar with Andy and we'll review, set expectations, update
tooling as necessary, and resubmit. Given the above Kconfig default,
we'll prepare a patch on top of the existing HEAD to default to No, and
create a new tag.

Appreciate the detail above, we'll make sure it doesn't get lost.

-- 
Darren Hart
VMware Open Source Technology Center