[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