From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751870AbdKTRRO (ORCPT ); Mon, 20 Nov 2017 12:17:14 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:53271 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbdKTRRN (ORCPT ); Mon, 20 Nov 2017 12:17:13 -0500 Date: Mon, 20 Nov 2017 09:17:11 -0800 From: Darren Hart To: Linus Torvalds Cc: Andy Shevchenko , LKML Subject: Re: [GIT PULL] platform-drivers-x86 for 4.15-1 Message-ID: <20171120171711.GA379@fury> References: <20171118180910.qzbuh4donbwrxbyg@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 18, 2017 at 12:09:10PM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:37 AM, Linus Torvalds > 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