[RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Grant Likely
grant.likely at secretlab.ca
Mon Jul 19 01:20:57 EDT 2010
On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <jamie at shareable.org> wrote:
> 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.
Just to be clear (specifically for me as a maintainer) the purpose of
defconfigs is not to provide the best optimized kernel configuration
for each given board. defconfigs are useful as a reasonable working
starting point, and to provide build coverage testing.
> 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.
Yes. The defconfig is only a starting point. Maintaining the actual
config for the shipped kernel is the job of the distribution vendor
and I have zero interest in maintaining those configurations in the
kernel tree.
g.
More information about the linux-arm-kernel
mailing list