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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Jul 2010 00:49:18 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Daniel Walker <dwalker@...eaurora.org>
Cc:	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,
	Grant Likely <grant.likely@...retlab.ca>,
	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

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.

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.

-- Jamie
--
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/