On Sat, Nov 18, 2017 at 12:09:10PM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:37 AM, Linus Torvalds > <[email protected]> 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
