linux-kernel - Re: kms in defconfig

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.DEB.1.10.0904280946210.17268@asgard.lang.hm>
Date:	Tue, 28 Apr 2009 09:54:18 -0700 (PDT)
From:	david@...g.hm
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Tejun Heo <tj@...nel.org>, Dave Airlie <airlied@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kms in defconfig

On Mon, 27 Apr 2009, Linus Torvalds wrote:

> On Tue, 28 Apr 2009, Tejun Heo wrote:
>>
>> I think defconfig should enable options such that it shows where
>> upstream kernel is headed, so FWIW +1 for KMS from me.
>
> I'd actually love to get rid of the stupid defconfig's entirely. They've
> lost pretty much all relevance over the years, except for specific cases
> where you might have defconfigs that are for specific platforms.
>
> IOW, the embedded kind of "per-platform defconfig" at lest is a useful
> starting point. But even there I'm not 100% sure that it makes sense to
> pollute the kernel source tree with them - they mess up things like
>
> 	git grep PREVENT_FIRMWARE_BUILD
>
> horribly.
>
> IOW, they're likely to be more pain than they are worth. And they really
> aren't useful starting points for normal people (who are probably better
> off starting with their distro kernel config) or likely even for most
> kernel developers (who hopefully have noticed that they can install a
> per-machine defconfig in /etc/kernel-config and forget about it).
>
> I'd love to just delete them all.

as a end-user creating my own configs, I use the defaults as a guide to 
understand when something moves from "we think it's a good idea" to 
"things really need this"

there's a _lot_ of stuff that goes in that is useful only is some 
situations, and the help text frequently doesn't help understanding what's 
really needed vs what the author of that feature _thinks_ is really needed 
(containers are a perfect example, they aren't needed in 99% of current 
systems, but it's actually _hard_ to really disable them completely)


you mention starting from a distro config, but most distro configs have a 
_huge_ number of things enabled that aren't needed for any particular box. 
right now it's significantly faster to start with a defconfig and enable 
hardware drivers than it is to start with a distro config and disable 
things. If a tool was available to detect the hardware and create a 
config tailored for the box, this use for a default config would go away

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/