Kconfig: Enable Kconfig fragments to be used for defconfig
in [Kernel]
|
Prev: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Next: Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely on 19 Jul 2010 01:30 On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <jamie(a)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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |