List Archive: gentoo-releng
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Sebastian Pipping <firstname.lastname@example.org>
[rfc] A new process for kernel config maintenance?
Fri, 17 Jun 2011 19:06:02 +0200
There are at least two sets of kernel configs in Gentoo: those in
genkernel  and those used with Gentoo live media .
Currently these configs are stored as a set of varying .config files.
This approach has a number of drawbacks:
- Keeping all arches in sync is cumbersome and prone to error
- No one really dares to touch non-mainstream configs and often
changes end up at x84 and x86_64 only.
- The config files carry no documentation on
- why a certain option was enabled or disabled and
- if that option is (A) default, (B) an intended choice or
(C) a consequence from a dependency,
which makes well-informed changes hard and means carrying
around lots of defaults of little value
I would like to discuss an idea of mine on improving the situation.
What if we had a single file with rules (declarative) or instructions
(imperative) like this:
if arch x86_64
# x86_64 doesn't like foo, therefore we do bar (bug #123456)
A tool would then
1) take defconfig of the arch (of any version of the kernel)
2) apply the requested changes
3) run "make silentoldconfig"(?) to fix config dependencies
Conditional checks could work on: arch, kernel version,
desktop/liveDVD/netboot environment, etc.
Would that work in theory? I suppose it would be easy to rip out the
part from the kernel necessary to make use of its "make silentoldconfig"
logic without re-implementing things. For 188.8.131.52 this tar command
seemed to ripp everything needed:
tar xf linux-184.108.40.206.tar.bz2 --wildcards \
A problem I am facing though is: how do I "make silentoldconfig" as if I
were on say sparc on my x86_64 box. Is that that no problem, a small or
a big one? Plain overridding of ARCH got me into compile errors.
Ignoring the work needed to reverse document our current configs for
now: What do you think about such an approach?
Thanks for your feedback, best,