On 4/22/2010 0:08, Roger Quadros wrote:
ext An Yang wrote:
� 2010-04-21�� 08:04 -0700�Greg KH���
As someone who has maintained kernels with a few dozen config files for
a long time, for different arches and flavors, no, this seems much
easier to keep everything in sync properly.
Let's try it and see, individual config files are very hard to ensure
that they are consistant.
absolutely right. consistant means less mistake.
but to solve is problem, the kernel maintainer should have a clear
maintain rules.
which driver should be in, which driver should be module, which driver
should be out?
Right.
This is what i think.
Minimally there should be 2 config files
1) config-generic
2) config-platform (e.g. config-menlow or config-n900)
config-generic should only stuff that is not specific to any
Architecture. It definitely cannot have any Kconfig option that comes
from arch directory. So usually config-generic would only contain
Network protocols, File systems. I don't think this should contain any
device driver options.
I disagree. It should be the superset of everything possible, as much as
possible.
That way, anything that is "don't care exactly" for a platform/board will be
consistent
no matter what.
I don't think it is necessary to have an additional config-arch-generic
for ARM since for example we can't have a config-arm-generic that keeps
all ARM platforms happy and is at the same time optimal.
actually that's based on an incorrect assumption. You can and should pick sane
arm defaults
that override config-generic... and specific boards then only need to do the
minimal deltas.
it's perfectly fine for a specific config option to be in all three of
config-generic, config-arch-generic
and config-board; the merge process will make sure that the board one wins..
but for all options that are not in config-board the generic ones win.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
