# how to tell if CONFIG option will be enabled w/o menuconfig

## dcljr

Is there any way of determining whether a specific kernel CONFIG option will be enabled or disabled by default without actually running make menuconfig and immediately saving it without making any changes?

In other words, can I accomplish this by just, say, find-ing and grep-ping the sources in a particular way?

----------

## N8Fear

grep CONFIG_<name> <path-to-sources>/.config should do that.

----------

## dcljr

 *N8Fear wrote:*   

> grep CONFIG_<name> <path-to-sources>/.config should do that.

 

But that only works after a .config has been created, which is done by running make menuconfig and saving. This is exactly what I'm trying to avoid.

Unless I am very much mistaken, newly emerged kernel sources don't come with a .config file...

----------

## Apheus

```
make defconfig
```

Or look at the defconfig files in arch/<arch>/configs. The <arch> for intel compatibles is "x86", with different defconfig files for 32 and 64 bit.

Also, "make help" informs about all the options.

----------

## dcljr

 *Apheus wrote:*   

> Or look at the defconfig files in arch/<arch>/configs.

 

That seems to be what I was looking for. I wanted to avoid all make commands.

----------

## dcljr

Or not.

The options listed in arch/config/x86_64_defconfig don't match what I got by make menconfig with immediate save (I'm on a stable amd64 system). Not only does each file list CONFIGs not in the other, but there are several options that are listed in both but enabled in one and disabled in the other.

(I guess this makes sense, since otherwise there would be no need to have a separate make defconfig command!)

Surprisingly, though, the arch/config/x86_64_defconfig that came with my 3.12.21-gentoo-r1 kernel reports at the top:

```
# Linux kernel version: 2.6.30-rc2

# Mon May 11 16:22:00 2009
```

Which is crazy out of date. Is this really what would be used if I were to do a make defconfig on my 3.12.21-gentoo-r1 kernel sources?? (I never actually use that command.)

I suspected that with all the interdependencies among CONFIGs it would be impossible to tell what would be enabled and disabled without using one of the make commands. Looks like I was right.

So, anyway, just to clarify:

 make menuconfig with immediate save sets CONFIGs to what gentoo-sources developers (*) see as default options

 make defconfig sets the CONFIGs to what upstream sees as default options

Is that at all correct?

EDIT: (*) assuming that's the kernel you're using, of course

----------

## Apheus

You are right, "make defconfig" does not yield the same file as in the "configs" directory:

```
18:56 build@kallisto /usr/src/linux-3.15.8-hardened $ md5sum arch/x86/configs/x86_64_defconfig 

0aca9e66eeddf2f813fd35603b0cf844  arch/x86/configs/x86_64_defconfig

18:56 build@kallisto /usr/src/linux-3.15.8-hardened $ md5sum ~/kernel/def/.config 

1d67936079f10ebfa2977854160fb917  /var/build//kernel/def/.config

18:57 build@kallisto /usr/src/linux-3.15.8-hardened $ md5sum ~/kernel/menu/.config 

1d67936079f10ebfa2977854160fb917  /var/build//kernel/menu/.config
```

However, in my case the files in the "configs" directory are not outdated. They do not contain a date comment at the beginning, they simply start with the CONFIG options. To be exact, this is the file

```
/usr/src/linux-3.15.8-hardened/arch/x86/configs/x86_64_defconfig
```

However, it seems you cannot get around code analysis, or running "make defconfig", unfortunately.

----------

## dcljr

 *Apheus wrote:*   

> You are right, "make defconfig" does not yield the same file as in the "configs" directory:

 

Oh, I didn't actually say that. But whatever...

 *Quote:*   

> However, in my case the files in the "configs" directory are not outdated. They do not contain a date comment at the beginning, they simply start with the CONFIG options. To be exact, this is the file
> 
> ```
> /usr/src/linux-3.15.8-hardened/arch/x86/configs/x86_64_defconfig
> ```
> ...

 

OMG, I just realized I quoted the x86_64_defconfig file from my current/old system instead of from my future/new system. (I've been sloooowly building a new Gentoo installation for over a month now...)

No wonder it was so out of date!

# head /usr/src/linux-2.6.31-gentoo-r10/arch/x86/configs/x86_64_defconfig

```
#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.30-rc2

# Mon May 11 16:22:00 2009

#

CONFIG_64BIT=y

# CONFIG_X86_32 is not set

CONFIG_X86_64=y

CONFIG_X86=y

CONFIG_OUTPUT_FORMAT="elf64-x86-64"
```

# head /mnt/gentoo/usr/src/linux-3.12.21-gentoo-r1/arch/x86/configs/x86_64_defconfig

```
CONFIG_EXPERIMENTAL=y

# CONFIG_LOCALVERSION_AUTO is not set

CONFIG_SYSVIPC=y

CONFIG_POSIX_MQUEUE=y

CONFIG_BSD_PROCESS_ACCT=y

CONFIG_TASKSTATS=y

CONFIG_TASK_DELAY_ACCT=y

CONFIG_TASK_XACCT=y

CONFIG_TASK_IO_ACCOUNTING=y

CONFIG_AUDIT=y
```

This second one is the relevant one, of course.

For the sake of completeness, here's the top of the .config resulting from a "null-menuconfig":

# head config-3.12.21-gentoo-r1_ORIGINAL

```
#

# Automatically generated file; DO NOT EDIT.

# Linux/x86 3.12.21-gentoo-r1 Kernel Configuration

#

#

# Gentoo Linux

#

CONFIG_GENTOO_LINUX=y

CONFIG_GENTOO_LINUX_UDEV=y
```

Which illustrates why the two approaches couldn't possibly give the same results: the "gentoo-sources" have been fiddled with by the Gentoo developers, but apparently they don't touch the "defconfig" files:

# grep GENTOO /mnt/gentoo/usr/src/linux-3.12.21-gentoo-r1/arch/x86/configs/x86_64_defconfig

```

```

(no output)

This supposition is verified by comparing this (3.12.21-gentoo-r1) "defconfig" file with one extracted from a linux-3.12.27.tar.xz tarball downloaded directly from kernel.org. The x86_64_defconfig files are identical.

----------

## dmpogo

If that option was enabled in kernel configuration,  config of the running kernel can be found in /proc/config.gz

----------

## Roman_Gruber

 *Apheus wrote:*   

> You are right, "make defconfig" does not yield the same file as in the "configs" directory:
> 
> ```
> 18:56 build@kallisto /usr/src/linux-3.15.8-hardened $ md5sum arch/x86/configs/x86_64_defconfig 
> 
> ...

 

are you sure the md5sum is identical with different file-names and file creation dates? I doubt.

It would not make much sense to use md5sum than for iso files to check them when you download them.

there used to be some diff progs available to check files ...

----------

## Apheus

 *tw04l124 wrote:*   

> 
> 
> are you sure the md5sum is identical with different file-names and file creation dates? I doubt.
> 
> It would not make much sense to use md5sum than for iso files to check them when you download them.
> ...

 

Md5sum reads the file's content and does not care about filesystem attributes like filename and dates. For iso checking, this is even necessary.

In my quoted case, "make menuconfig" with immediate exit created completely the same .config like "make defconfig".

----------

## dcljr

Well, damn. It's more complicated than I thought, apparently.

When I logged into my new Gentoo system (running a gentoo-sources-3.12.21-r1 kernel), emerged the latest stable sources (gentoo-sources-3.14.14), eselected the new kernel (to update the /usr/src/linux symlink), cd'd to that directory, and executed make menuconfig, I immediately noticed that it had picked up my old config settings because I saw the "LOCALVERSION" name I used for 3.12.21-r1 in the "General setup" submenu. I double-checked, and I really was in the 3.14.14 sources tree.

So, even though I ran make menuconfig (not make oldconfig) with no /usr/src/linux/.config* present (or any /usr/src/linux/config*, for that matter), it still found and used my old 3.12.21-r1 configuration!

Witness:

grep -P "gen|LOCALVERSION" config_3.14.14-gentoo.NULL_MENUCONFIG

```
# Automatically generated file; DO NOT EDIT.

# Linux/x86 3.14.14-gentoo Kernel Configuration

CONFIG_LOCALVERSION="-ice"

# CONFIG_LOCALVERSION_AUTO is not set

# PPS generators support
```

(The suffix "-ice" refers to my soundcard driver, the last thing I changed about my 3.12.21-r1 configuration before building that kernel for the last time.)

Note that I built 3.12.21-r1 with the options that save a copy of the config in the running kernel and makes the config available at /proc/config.gz, and saved the config file on the boot partition (default behavior of make install). According to this forum post from 2011, a config file for the same version kernel on /boot will be used by make menuconfig when rebuilding the same version kernel. Is that also true when building a kernel with a higher "major" version number (3.12.21-r1 to 3.14.14)? Doesn't seem like this should be the case, since otherwise make oldconfig would be redundant (unless there's a more subtle difference between the two make commands).

So I guess I'll try configuring 3.14.14 again with my boot partition unmounted (note that I have not actually built a 3.14.14 kernel yet), and see if that does what I want (which, just to be clear, is to get a .config file that is as independent of the configuration of the currently running kernel, and of any past kernels, as possible).

EDIT: Corrected the location of the "LOCALVERSION" config option.Last edited by dcljr on Fri Oct 03, 2014 7:00 am; edited 1 time in total

----------

## dcljr

 *dcljr wrote:*   

> see if that does what I want (which, just to be clear, is to get a .config file that is as independent of the configuration of the currently running kernel, and of any past kernels, as possible).

 

Not counting something like make randconfig, of course! :)

I guess I should "come clean" and say exactly what I'm trying to accomplish....

When I built my 3.12.21-r1 kernel, the CONFIG_DEBUG_STACK_USAGE option was enabled (not intentionally by me), resulting in scary looking warnings appearing in the kernel log (dmesg). I submitted a bug at bugzilla.kernel.org, suggesting that the warning messages could be improved to help users who didn't intentionally set that option. The respondents essentially said that shouldn't happen and closed the bug, first as WILL_NOT_FIX and then (after I reopened it) as INVALID, saying it was a Gentoo problem. When I submitted a bug to Gentoo's Bugzilla suggesting that the option shouldn't be turned on by default, someone replied saying "gentoo-sources doesn't set this - it's upstream."

So... no one wants to take responsibility for this option being turned on without users' knowledge/consent, and I still don't know how it got turned on in my .config in the first place. It was not turned on, or even present in the .config file at all, in my 2.6.31-r10 kernel, which was the running kernel when I initially built 3.12.21-r1. (Although my 2.6.31-r10 did have the options CONFIG_STACKTRACE_SUPPORT and CONFIG_USER_STACKTRACE_SUPPORT enabled -- not sure that's even relevant.)

So that's why I was asking for a way of finding out if a particular option was going to be enabled by default without actually make-ing anything. Now I'd settle for actually using make to get a "default" configuration file that doesn't depend on what I have ever done in the past, and only depends on what gentoo kernel developers and/or Kernel.org developers have chosen as "default" configuration options. (Once I know how to do this, I can do it on a gentoo-sources tree and a kernel.org tree and compare the two. I haven't actually tried make <whatever> on a Kernel.org kernel yet.)

----------

## Hu

Use make defconfig.  I have never seen DEBUG_STACK_USAGE switch on without user intervention.

----------

## dcljr

 *Hu wrote:*   

> Use make defconfig.

 

OK, that's what I initially thought would give me the "Kernel.org developers' defaults". (Granted, I was talking about the file /usr/src/linux/arch/x86/configs/x86_64_defconfig and not the result of running make defconfig on an x86_64 system, but I had assumed they were equivalent. More about this below.)

If you haven't already read my bugzilla.kernel.org bug report (linked to in my last post), I was told that "The kernel.org defaults are for developers not for end users", so they didn't accept "CONFIG_DEBUG_STACK_USAGE=y" showing up in a Kernel.org-supplied arch/x86/configs/x86_64_defconfig file as evidence that they were turning on the stack debugging option for end-users.

Anyway... so I finally went back into my "new" (kernel-3.12.21-gentoo-r1-ice) system for more testing (again, using the latest-stable gentoo-sources-3.14.14).

The following three methods created exactly the same .config:

make menuconfig with immediate save and exit, with boot partition not mounted and no prior /usr/src/linux/.config*

make defconfig, with boot partition not mounted and no prior /usr/src/linux/.config*

make defconfig, with boot partition mounted and no prior /usr/src/linux/.config*

For this .config:

# grep -P "DEBUG_STACK|LOCALVERSION" config_3.14.14-gentoo.DEFCONFIG_BOOT_NOT_MOUNTED

```
CONFIG_LOCALVERSION=""

# CONFIG_LOCALVERSION_AUTO is not set

CONFIG_DEBUG_STACK_USAGE=y

CONFIG_HAVE_DEBUG_STACKOVERFLOW=y

CONFIG_DEBUG_STACKOVERFLOW=y
```

The following method created a different .config -- one "polluted" by the configuration found at /boot/config-3.12.21-gentoo-r1-ice:

make menuconfig with immediate save and exit, with boot partition mounted and no prior /usr/src/linux/.config*

And, of course, for this .config:

# grep -P "DEBUG_STACK|LOCALVERSION" config_3.14.14-gentoo.NULL_MENUCONFIG_BOOT_MOUNTED

```
CONFIG_LOCALVERSION="-ice"

# CONFIG_LOCALVERSION_AUTO is not set

CONFIG_DEBUG_STACK_USAGE=y

CONFIG_HAVE_DEBUG_STACKOVERFLOW=y

CONFIG_DEBUG_STACKOVERFLOW=y
```

So, no matter what, I'm getting DEBUG_STACK_USAGE turned on. (Again, I stress, these are kernel sources that have never had anything done to them beyond running make menconfig -- and now make defconfig -- and each time I have immediately moved the resulting .config out of /usr/src/linux/.)

Now...

# grep -A 7 DEBUG_STACK_USAGE /usr/src/linux-3.14.14-gentoo/lib/Kconfig.debug

```
config DEBUG_STACK_USAGE

   bool "Stack utilization instrumentation"

   depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG

   help

     Enables the display of the minimum amount of free stack which each

     task has ever had available in the sysrq-T and sysrq-P debug output.

     This option will slow down process creation somewhat.
```

And...

# tail -n +3140 config_3.14.14-gentoo.DEFCONFIG_BOOT_NOT_MOUNTED | head -n 157

```
CONFIG_DEBUG_KERNEL=y

#

# Memory Debugging

#

# CONFIG_DEBUG_PAGEALLOC is not set

# CONFIG_DEBUG_OBJECTS is not set

# CONFIG_SLUB_DEBUG_ON is not set

# CONFIG_SLUB_STATS is not set

CONFIG_HAVE_DEBUG_KMEMLEAK=y

# CONFIG_DEBUG_KMEMLEAK is not set

CONFIG_DEBUG_STACK_USAGE=y

# CONFIG_DEBUG_VM is not set

# CONFIG_DEBUG_VIRTUAL is not set

CONFIG_DEBUG_MEMORY_INIT=y

# CONFIG_DEBUG_PER_CPU_MAPS is not set

CONFIG_HAVE_DEBUG_STACKOVERFLOW=y

CONFIG_DEBUG_STACKOVERFLOW=y

CONFIG_HAVE_ARCH_KMEMCHECK=y

# CONFIG_KMEMCHECK is not set

# CONFIG_DEBUG_SHIRQ is not set

#

# Debug Lockups and Hangs

#

# CONFIG_LOCKUP_DETECTOR is not set

# CONFIG_DETECT_HUNG_TASK is not set

# CONFIG_PANIC_ON_OOPS is not set

CONFIG_PANIC_ON_OOPS_VALUE=0

CONFIG_PANIC_TIMEOUT=0

# CONFIG_SCHED_DEBUG is not set

CONFIG_SCHEDSTATS=y

CONFIG_TIMER_STATS=y

#

# Lock Debugging (spinlocks, mutexes, etc...)

#

# CONFIG_DEBUG_RT_MUTEXES is not set

# CONFIG_RT_MUTEX_TESTER is not set

# CONFIG_DEBUG_SPINLOCK is not set

# CONFIG_DEBUG_MUTEXES is not set

# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set

# CONFIG_DEBUG_LOCK_ALLOC is not set

# CONFIG_PROVE_LOCKING is not set

# CONFIG_LOCK_STAT is not set

# CONFIG_DEBUG_ATOMIC_SLEEP is not set

# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set

CONFIG_STACKTRACE=y

# CONFIG_DEBUG_KOBJECT is not set

CONFIG_DEBUG_BUGVERBOSE=y

# CONFIG_DEBUG_WRITECOUNT is not set

# CONFIG_DEBUG_LIST is not set

# CONFIG_DEBUG_SG is not set

# CONFIG_DEBUG_NOTIFIERS is not set

# CONFIG_DEBUG_CREDENTIALS is not set

#

# RCU Debugging

#

# CONFIG_SPARSE_RCU_POINTER is not set

# CONFIG_RCU_TORTURE_TEST is not set

CONFIG_RCU_CPU_STALL_TIMEOUT=21

# CONFIG_RCU_CPU_STALL_INFO is not set

# CONFIG_RCU_TRACE is not set

# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set

# CONFIG_NOTIFIER_ERROR_INJECTION is not set

# CONFIG_FAULT_INJECTION is not set

# CONFIG_LATENCYTOP is not set

CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y

# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

CONFIG_USER_STACKTRACE_SUPPORT=y

CONFIG_NOP_TRACER=y

CONFIG_HAVE_FUNCTION_TRACER=y

CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y

CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y

CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y

CONFIG_HAVE_DYNAMIC_FTRACE=y

CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y

CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y

CONFIG_HAVE_SYSCALL_TRACEPOINTS=y

CONFIG_HAVE_FENTRY=y

CONFIG_HAVE_C_RECORDMCOUNT=y

CONFIG_TRACE_CLOCK=y

CONFIG_RING_BUFFER=y

CONFIG_EVENT_TRACING=y

CONFIG_CONTEXT_SWITCH_TRACER=y

CONFIG_TRACING=y

CONFIG_GENERIC_TRACER=y

CONFIG_TRACING_SUPPORT=y

CONFIG_FTRACE=y

# CONFIG_FUNCTION_TRACER is not set

# CONFIG_IRQSOFF_TRACER is not set

# CONFIG_SCHED_TRACER is not set

# CONFIG_FTRACE_SYSCALLS is not set

# CONFIG_TRACER_SNAPSHOT is not set

CONFIG_BRANCH_PROFILE_NONE=y

# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set

# CONFIG_PROFILE_ALL_BRANCHES is not set

# CONFIG_STACK_TRACER is not set

CONFIG_BLK_DEV_IO_TRACE=y

CONFIG_KPROBE_EVENT=y

# CONFIG_UPROBE_EVENT is not set

CONFIG_PROBE_EVENTS=y

# CONFIG_FTRACE_STARTUP_TEST is not set

# CONFIG_MMIOTRACE is not set

# CONFIG_RING_BUFFER_BENCHMARK is not set

# CONFIG_RING_BUFFER_STARTUP_TEST is not set

#

# Runtime Testing

#

# CONFIG_LKDTM is not set

# CONFIG_TEST_LIST_SORT is not set

# CONFIG_KPROBES_SANITY_TEST is not set

# CONFIG_BACKTRACE_SELF_TEST is not set

# CONFIG_RBTREE_TEST is not set

# CONFIG_INTERVAL_TREE_TEST is not set

# CONFIG_PERCPU_TEST is not set

# CONFIG_ATOMIC64_SELFTEST is not set

# CONFIG_TEST_STRING_HELPERS is not set

# CONFIG_TEST_KSTRTOX is not set

CONFIG_PROVIDE_OHCI1394_DMA_INIT=y

# CONFIG_DMA_API_DEBUG is not set

# CONFIG_TEST_MODULE is not set

# CONFIG_TEST_USER_COPY is not set

# CONFIG_SAMPLES is not set

CONFIG_HAVE_ARCH_KGDB=y

# CONFIG_KGDB is not set

# CONFIG_STRICT_DEVMEM is not set

CONFIG_X86_VERBOSE_BOOTUP=y

CONFIG_EARLY_PRINTK=y

CONFIG_EARLY_PRINTK_DBGP=y

# CONFIG_EARLY_PRINTK_EFI is not set

# CONFIG_X86_PTDUMP is not set

CONFIG_DEBUG_RODATA=y

# CONFIG_DEBUG_RODATA_TEST is not set

# CONFIG_DEBUG_SET_MODULE_RONX is not set

# CONFIG_DEBUG_NX_TEST is not set

CONFIG_DOUBLEFAULT=y

# CONFIG_DEBUG_TLBFLUSH is not set

# CONFIG_IOMMU_STRESS is not set

CONFIG_HAVE_MMIOTRACE_SUPPORT=y

# CONFIG_X86_DECODER_SELFTEST is not set

CONFIG_IO_DELAY_TYPE_0X80=0

CONFIG_IO_DELAY_TYPE_0XED=1

CONFIG_IO_DELAY_TYPE_UDELAY=2

CONFIG_IO_DELAY_TYPE_NONE=3

CONFIG_IO_DELAY_0X80=y

# CONFIG_IO_DELAY_0XED is not set

# CONFIG_IO_DELAY_UDELAY is not set

# CONFIG_IO_DELAY_NONE is not set

CONFIG_DEFAULT_IO_DELAY_TYPE=0

CONFIG_DEBUG_BOOT_PARAMS=y

# CONFIG_CPA_DEBUG is not set

CONFIG_OPTIMIZE_INLINING=y

# CONFIG_DEBUG_NMI_SELFTEST is not set

# CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set
```

So, I'm getting a whole bunch of "Kernel debugging" options besides the ones I've been complaining about. (Note that DEBUG_KERNEL was not enabled in my 2.6.31-gentoo-r1 kernel.)

Ultimately, the fact that I'm getting DEBUG_STACK_USAGE enabled is the "responsibility" of the Gentoo kernel developers, right? Even if, as the Gentoo Bugzilla commenter said, "gentoo-sources doesn't set this - it's upstream", it is the responsibility of the Gentoo kernel developers to disable any debugging options not needed by their end-users, right?

And finally... like I said, I had assumed that the options listed in /usr/src/linux/arch/x86/configs/x86_64_defconfig would actually be in the .config resulting from make defconfig on an x86_64 system. Again, I was wrong:

# grep -P "EXPERIMENTAL|NF_NAT" /usr/src/linux-3.14.14-gentoo/arch/x86/configs/x86_64_defconfig

```
CONFIG_EXPERIMENTAL=y

CONFIG_NF_NAT=y
```

# grep -P "EXPERIMENTAL|NF_NAT" config_3.14.14-gentoo.DEFCONFIG_BOOT_NOT_MOUNTED

```
CONFIG_NF_NAT=m

CONFIG_NF_NAT_NEEDED=y

# CONFIG_NF_NAT_AMANDA is not set

CONFIG_NF_NAT_FTP=m

CONFIG_NF_NAT_IRC=m

CONFIG_NF_NAT_SIP=m

# CONFIG_NF_NAT_TFTP is not set

CONFIG_NF_NAT_IPV4=m

# CONFIG_NF_NAT_PPTP is not set

# CONFIG_NF_NAT_H323 is not set
```

Notice how EXPERIMENTAL disappeared and NF_NAT became a module instead of a built-in. (These are just "random" examples I picked out of a rather large diff.)

Presumably this is evidence that make defconfig (on gentoo-sources-*) really does give the Gentoo kernel developers' defaults and not the Kernel.org developers' defaults, as I suggested in my fourth post above.

Oh, and for the sake of completeness:

# grep -P "DEBUG_STACK|LOCALVERSION" /mnt/gentoo/usr/src/linux-3.14.14-gentoo/arch/x86/configs/x86_64_defconfig

```
# CONFIG_LOCALVERSION_AUTO is not set

CONFIG_DEBUG_STACK_USAGE=y

CONFIG_DEBUG_STACKOVERFLOW=y
```

----------

