Re: kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)

[Sam Ravnborg <sam@ravnborg.org>]

On Sun, Sep 02, 2007 at 02:02:37AM +0200, Oleg Verych wrote:
> * Sun, 26 Aug 2007 01:08:28 -0500
> * Organization: Boundaries Unlimited
> >
> []
> > Also "here's a symbol, show me a menu containing everything else that is 
> > either required by or enabled by this symbol..."  That sounds like a more 
> > powerful abstraction, since the previous one is "show me everything that 
> > depends on CONFIG_BLOCK".
> >
> > (I wonder if this would be a largeish rewrite of the menuconfig 
> > infrastructure?  Hmmm...)
> 
> Yess. I'm doing this, actually. Sam, Andrew and Linus have got an email
> half a year ago about my intent. Tried to release 2.6.20-j4f, but that
> was just a dream. Now i did some training in non-kernel related stuff and
> always catch (30k, 14k) LKML backlogs to stay in tune. Some bits i 
> get are here ftp://flower.upol.cz/Linux/info-LKML/tools/
> 
> So, ideas: UI, organization, efficiency, simplicity, etc. are welcome.
> 
> Maybe in one month i'll get something to show (base is 2.6.22).
> Imagination plays very well, the thing must be ground shaking, but i'll
> see how it will fit reality. Yours one in consideration from very
> beginning, don't bother :)
Then as now you have not yet expalined what you are trying to do.
Nevertheless I look forward for a minmal set of patches that improve
whatever you are working with.

As for Kconfig the low hanging fruits are not in the tools but in the
structure of the Kconfig files. There are a lot that can be improved
with a decent effort but nobody has stepped up doing so.
The tools could be better too but if the root problem is the structure
of the Kconfig files this is where we should focus and not on the tools.

For Kbuild I fail to see anything that demand a rewrite from a structure
view of the Kbuild files.
The Kbuild internal stuff is antoehr story - here a rewrite to a saner
language then GNU make syntax could improve hackability a lot.

	Sam