lkml.org 
[lkml]   [2010]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From
Date
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.



\
 
 \ /
  Last update: 2010-07-14 18:25    [W:0.052 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site