linux-kernel - Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for 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] [day] [month] [year] [list]

Date:	Sun, 18 Jul 2010 23:20:57 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	Nicolas Pitre <nico@...xnic.net>, linux-kbuild@...r.kernel.org,
	Tony Lindgren <tony@...mide.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King <rmk@....linux.org.uk>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, linuxppc-dev@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for 
	defconfig

On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <jamie@...reable.org> wrote:
> Daniel Walker wrote:
>> > But all the rest is arbitrary and could be part of common shared
>> > profiles or the like in defconfig format.
>>
>> I'm sure most people will want to have a config isolated to their
>> specific device. That to me seems reasonable because everyone wants the
>> smallest possible kernel they can get for their given device.

Just to be clear (specifically for me as a maintainer) the purpose of
defconfigs is not to provide the best optimized kernel configuration
for each given board.  defconfigs are useful as a reasonable working
starting point, and to provide build coverage testing.

> Indeed, but people who want the smallest possible kernel for their
> specific device _in a particular use context_ tend to want:
>
>  - To disable support for parts of the device they aren't using.
>    For example, an SoC with integrated ethernet that isn't actually
>    wired up on their board, or where they're using an external ethernet
>    chip instead for some reason.
>
>  - To choose what's modular and what isn't, even for integrated
>    parts.  For example to control the bootup sequence, they might
>    want to delay integrated USB and IDE initialisation, which is done by
>    making those modular and loading them after bringing up a splash
>    screen earlier in the boot scripts.
>
> So there is still a need to be able to override the drivers and
> settings, but it's still incredibly useful to have defaults which
> describe the SoC or board accurately.

Yes.  The defconfig is only a starting point.  Maintaining the actual
config for the shipped kernel is the job of the distribution vendor
and I have zero interest in maintaining those configurations in the
kernel tree.

g.
--
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/