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

On Tue, 2010-07-13 at 20:07 -0400, Nicolas Pitre wrote:

> That's one issue indeed.
> 
> But there is another issue that is somewhat related, which is to be able 
> to categorize config options.
> 
> Currently the defconfig files carry information about the proper driver 
> to enable in order to support devices soldered on the board and 
> therefore which are not "optional".  That might be a particular RTC 
> chip, or a particular ethernet block integrated into a SOC, etc.  Of 
> course we want to preserve the ability to disable support for those 
> things, but by default people want to have all the right drivers 
> selected for all the built-in hardware when selecting a target 
> machine/board without having to dig into a datasheet for that target.
> 
> The defconfig files also carry config options that are totally 
> arbitrary.  What type of filesystem, what kind of network protocol, what 
> USB device drivers (not host controller driver), what amount of 
> debugging options, all those are unrelated to the actual hardware and 
> may vary from one user to another.

Right.

> Furthermore, in order to reduce the number of defconfig files, we tried 
> to combine as many targets into a single kernel image.  That increases 
> build test coverage with fewer builds which is good, but then the info 
> about specific drivers required for a specific target but not for 
> another target in the same defconfig is now lost.  It is therefore quite 
> hard to produce a highly optimized configuration for a single target 
> without doing some digging again.
> 
> So it is really in the Kconfig file that all those hardware specific 
> options can be expressed in a clear and readable way.  When BOARD_XYZ is 
> selected and STD_CONFIG is selected, then automatically select RTC_FOO, 
> select ETH_BAR, select LED_BAZ, etc. Of course we would want required 
> dependencies to be automatically selected as well.

I see..

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

Then there would be a smaller group who wants to create multi-device
images. I don't see this being the average users tho, or kernel hackers.

To me there is little difference between doing,

CONFIG_ARCH_MSM=y

or

select ARCH_MSM

they are basically doing the same thing. So doing anything in Kconfig is
a lateral move .. Converting over to Kconfig in this case doesn't makes
sense to me.

Could we do something more like adding an "#include" option into the
defconfigs .. Then you could create defconfigs that hold multiple
devices without a massive rework to what we currently have. 

Daniel


-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

Powered by blists - more mailing lists