FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Releng

LinkBack Thread Tools
Old 06-17-2011, 05:06 PM
Sebastian Pipping
Default A new process for kernel config maintenance?

Hello everyone!

There are at least two sets of kernel configs in Gentoo: those in
genkernel [1] and those used with Gentoo live media [2].

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 this tar command
seemed to ripp everything needed:

tar xf linux- --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,



Thread Tools

All times are GMT. The time now is 11:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org