lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@linux-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

\
 
 \ /
  Last update: 2017-11-20 18:18    [W:0.071 / U:15.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site