[PATCH] Kconfig: sync with linux kernel v2.6.35-4771-g1787985

[Sam Ravnborg]

On Sun, Aug 08, 2010 at 11:06:12AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi sam,
> > 
> > In the kconfig land we are workng on an enhancement to
> > nconf so we replace the "use first or second char in  menu as hotkey".
> > The initial reason why we started this was that people
> > did not like that some menus had the second char
> > capitalized like this:
> > 
> >    "mOdule support"
> > 
> > The reason why "O" is capital and not "m" is that "m" hotkey
> > is already in use. And we use the capital letter to signal
> > the relevant hotkey.
> > menuconfig does so using a different color, but the
> > high level ncurses interface nconfig uses does not allow this.
> I notice this and does not like it also
> why not underline it?

That was not possible with the high-level interface nconfig uses.
Nir used a new approach where he uses an interactive search
and the interactive search will match any menu containing
the string entered.

More powerfull than the hot-key support, and more flexible.

> > We are also working on a fix to savedefconfig.
> > savedefconfig is a new target used to save a minimal config.
> > 
> > So all-in-all I would like to see this sync happen
> > either a bit later this kernel cycle, or that you
> > resync again later in this cycle.
> > 
> > Which bring up another question.
> > We have plenty of projects out there that rely
> > on kconfig.
> > What can we do to kconfig to make the integration easier?
> > 
> > We have discussed that kconfig should be a seperate
> > installable tool (as rpm, deb whatever).
> > But there is a few quirks needed before we can do so.
> I prefer to umbedeed it is the source so we can control which version we use
> and no need to rely on too much external stuff
OK, I will drop any thinking of packaging it as an external tool.
[I was not sure how to do this so glad to drop it].

> > 
> > But are there any other thing we could do to
> > make life easier for external users?
> infact yes if the project name could be configurable it will avoid to modify
> it and we could use it as is
> 
> I've notice 3 names
> 
> kernel,
> Kernel,
> Linux Kernel
> 
> if instead of hard coding it we could use a symbol to configure it it will
> make it integrable as is
> 
> one other think it will be good to avoid KERNEL something in the env or the
> default symbol and use a more generic one as for KERNELVERSION use
> RELEASEVERSION as example

They should obviously go. I have had patches to do so before but I did
not like them so they never got applied.
I will try to cook up something and let see what Michal thinks.
[Michal takes care of kconfig these days, I just do some random
patches when I feel in the mode to do so].

> 
> also a small doc for the mandatory env and symbol will be nice for people to
> integrate it as not everyone is also a kernel dev or maintainer

I actually take this that integrating kconfig should be simpler.
So it:
a) should be documented using a HOW-TO
b) we sould rely on very little outside scripts/kconfig

The primary 'customer' is the kernel but it would be good
to generalize stuff a bit more.
This is by far the biggest task listed.
I will add it to my mental TODO list - but no promises :-) 

> 
> and a last thing It will be nice to be able to set a value to a symbol from an
> other one and not only select it

I am not sure I see how this is usefull.
Can you give me an example.

Note: We recently had a patch where "select" was extended to
specify an optional value.
But my issue with that was that I failed to see the use of it so
I was not happy with the extension.

But I may have missed something!

Thanks for the quick feedback!

	Sam