[PATCH 00/12][RFC] Intial Kconfig Fragment Demo
john.rigby at linaro.org
Wed Mar 9 21:58:32 UTC 2011
On Wed, Mar 9, 2011 at 11:18 AM, John Stultz <john.stultz at linaro.org> wrote:
> On Wed, 2011-03-09 at 10:17 +0200, Amit Kucheria wrote:
>> On Wed, Mar 9, 2011 at 4:32 AM, John Stultz <john.stultz at linaro.org> wrote:
>> > My solution is to have a Kconfig.distro file, which is patched
>> > with Distro specific policy config, such as which filesystems
>> > should be enabled, networking policy, debug options, or periphrial
>> > driver modules that should be enabled. Basically anything that
>> > isn't hardware specific (by that I mean, part of the architecture
>> > or wired on the board).
>> The Ubuntu configs do something similar. The config generator makes a
>> 3-level config - distro, arch, board.
>> But this is encapsulated under the debian packaging rather than in the
>> kernel source. That is why you probably haven't seen it yet. Look at
>> git://git.linaro.org/ubuntu/linux-linaro-natty.git under
>> Most kernel developers, however, don't really care about creating a
>> .deb package of the kernel to test new code. They'd rather have the
>> config available in the sources. So I agree that we should fix this
>> problem for them. If it turns out that in fixing this problem we fix
>> it for distros too, great!
> Yea, I am aware of some of the approaches that distros use, usually
> assembling .config fragments into a larger config at build time.
> And its in part because each distro has tried to solve the same issue
> out of the kernel that I'm interested in trying to solve the problem in
> the kernel source at the Kconfig level.
>> > From there, I add in as much of the generic Linaro config policy
>> > as I could, utilizing the config files that were used to build
>> > the omap3, imx51 and vexpress hardware packs.
>> > Since the Linaro config polciy is not unified at this point
>> > (in other words, each board has totally different set of generic
>> > policy options configured). I added the per target differences
>> > into the board kconfig fragments.
>> No, it doesn't. The system they use allows for unified configs. The
>> Ubuntu kernel has unified configs across 3-4 architectures.
> Huh. Are you sure? Because the configs found in the hwpacks are very
> different. I'll grant that the build system allows for unified config,
> but I don't think the Linaro kernels are making much use of it.
> omap vs vexpress being the best example of really wide differences:
> o cgroup support
> o bsd process accounting
> o xattr support for ext3/ext4
> o different preempt models
> o highres timers & no_hz
Yes, the configs in the packaged kernel are not in sync. The reason
is mostly historical. The omap config started with a ubuntu kernel
config which is indeed unified across arches so it has lots of stuff
on that we probably don't need in a linaro kernel.
The other configs started as configs from the kernel def configs plus
whatever it took to make the config checker happy (things like
security issues). We probably would not break may linaro supported
platforms if we stripped down the omap config to be more similar to
the other SOCs. I thought at one time that this was not a good idea
because there was a plan for ubuntu to use the linaro omap kernel.
That has not yet happened so at this time having the linaro omap
kernel config out of sync with the ubuntu one may not be a problem.
>> The problem is starting a new config for a new board/SoC. The current
>> config system expects a full config for the board dropped into place
>> and then let the tool split it out into distro/arch and board
>> components. If this causes any changes to the distro/arch configs, you
>> know you might have missed some options.
> I'll have to take a look at this.
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
More information about the linaro-dev