On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier [off-list ref] wrote:

Daniel Walker wrote:

quoted

quoted

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:

=A0- To disable support for parts of the device they aren't using.
=A0 =A0For example, an SoC with integrated ethernet that isn't actually
=A0 =A0wired up on their board, or where they're using an external ethern=

et

=A0 =A0chip instead for some reason.

=A0- To choose what's modular and what isn't, even for integrated
=A0 =A0parts. =A0For example to control the bootup sequence, they might
=A0 =A0want to delay integrated USB and IDE initialisation, which is done=

 by

=A0 =A0making those modular and loading them after bringing up a splash
=A0 =A0screen 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.