How exactly does `make menuconfig' work?

How exactly does `make menuconfig' work?

[Sebastian Tennant]

Hi all,

If it's a festive time of year in your part of the world, then I hope
you're enjoying it.

In a freshly unpacked kernel source, if I run:

  $ make allnoconfig

... it generates a minimal config with all options set to `no' which I can
then peruse with `make menuconfig', switching things `on' rather than
`off'.

This sounds fine, but...

... when I did this, there was simply no vesafb graphics option, which
I need.  In fact, the only way I can gain access to this option is to
base my new config on my existing one in /boot (which already includes
it) by expliciting loading it as an `alternative'.

Why is this?

I had been lead to believe that running:

  $ make menuconfig

... in a freshly unpacked kernel source automatically bases the new
config on your existing config.  I thought this was the case until I
came to the missing vesafb option.  I then tried running `make
mrpoper' and copying my config from /boot to the unpacked source
directory (as was suggested in another document) before running `make
menuconfig' again but still no vesafb option!

In short, I'm a little confused.

1) Why doesn't `make allnoconfig' include the veasfb graphics option?
2) Does a clean `make menuconfig' consult /boot/config-x.x.x or not?

I'd be extrememly grateful if someone could provide me with a clear
overview of the `make *config' process.

sdt

Re: How exactly does `make menuconfig' work?

[network_gauner]

> ...
>   $ make allnoconfig
> ...
> ... it generates a minimal config with all options set to `no' which I can
> then peruse with `make menuconfig', switching things `on' rather than
> `off'.
> 
> This sounds fine, but...
> 
> ... when I did this, there was simply no vesafb graphics option, which
> I need.  In fact, the only way I can gain access to this option is to
> base my new config on my existing one in /boot (which already includes
> it) by expliciting loading it as an `alternative'.
> 
> Why is this?

I don't know, but I think it should be caused by some option turned off. 
For example if you turn off ISA support, all options which are dependent 
on ISA disappear.

> I had been lead to believe that running:
> 
>   $ make menuconfig
> 
> ... in a freshly unpacked kernel source automatically bases the new
> config on your existing config.  I thought this was the case until I
> came to the missing vesafb option.  I then tried running `make
> mrpoper' and copying my config from /boot to the unpacked source
> directory (as was suggested in another document) before running `make
> menuconfig' again but still no vesafb option!

Try copying your old .config and do "make oldconfig" and then "make 
menuconfig". Make oldconfig updates your .config to suite kernel version 
you are going to compile.

Hope this helps.


Zdenek

Re: How exactly does `make menuconfig' work?

[Andy Davidson]

network_gauner wrote:
 > Sebastian Tennant wrote:
>> ... when I did this, there was simply no vesafb graphics option, which
>> I need.  In fact, the only way I can gain access to this option is to
>> base my new config on my existing one in /boot (which already includes
>> it) by expliciting loading it as an `alternative'.
>> Why is this?
> I don't know, but I think it should be caused by some option turned off. 
> For example if you turn off ISA support, all options which are dependent 
> on ISA disappear.

Assuming you want to turn CONFIG_VESA_FB on (?) drivers/video/Kconfig 
holds the key here.

config FB_VESA
         bool "VESA VGA graphics support"
         depends on (FB = y) && X86
         select FB_CFB_FILLRECT
         select FB_CFB_COPYAREA
         select FB_CFB_IMAGEBLIT

So you need 'Support for frame buffer devices' turned on, and X86 to be 
set to 'y'.  Check your .config file that make menuconfig saves for both 
of these.  I'm wondering whether you have, say, 'CONFIG_X86_32=y' but 
not 'CONFIG_X86=y'.

Why turn all of your .config defaults to 'no' anyway ?  This is the 
underlying cause of your trouble.

>> I had been lead to believe that running:
>>   $ make menuconfig
>> ... in a freshly unpacked kernel source automatically bases the new
>> config on your existing config.  I thought this was the case until I
>> came to the missing vesafb option.

Perhaps you may find that your distribution has kindly turned on the 
feature which stores the config file in /proc - in which case :

zcat /proc/config.gz > .config

will restore the config you used last time.  They also may store the 
.config in /boot (debian does - e.g. config-2.6.8-2-686, 
config-2.6.15-rc3-mm1)

cheers
-a