On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <jamie@xxxxxxxxxxxxx> 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-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
