[RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
dwalker at codeaurora.org
Thu Jul 15 02:22:43 EST 2010
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.
> 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.
> 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,
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.
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
More information about the Linuxppc-dev