make olddefconfig surprises

make olddefconfig surprises

[Song Liu]

Hi,

I was surprised by "make olddefconfig". Reporting here in case this is
something worth fixing/changing.

Here is what I see:

With make defconfig, CONFIG_DEVTMPFS is enabled:

$ make defconfig
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
$ grep CONFIG_DEVTMPFS .config
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_DEVTMPFS_SAFE is not set

But with make olddefconfig and an empty .config file,
CONFIG_DEVTMPFS is disabled:

$ echo > .config
$ make olddefconfig
#
# configuration written to .config
#
$ grep CONFIG_DEVTMPFS .config
# CONFIG_DEVTMPFS is not set

In the meanwhile, CONFIG_DEVTMPFS is enabled in my /proc/config.gz
and /boot/config*

I checked with a few folks. They were also surprised by this.

I think the logic of "make olddefconfig" is: With a .config, olddefconfig will
not look at other defaults (x86_64_defconfig, /proc/config.gz, /boot/config*,
etc.). Instead, olddefconfig only follows Kconfig files. If a config doesn't
have "default=y" in Kconfig files, it will be disabled.

This is confusing to users. For example, selftests users often have
a config file in "tools/testing/selftests/*/config" showing which configs are
needed for the tests to pass. The expectation is: default config with these
changes will work. However, this is actually not the case. Many of these
config files actually have "CONFIG_DEVTMPFS=y" to make it work.

So, the question is, shall we change the behavior of olddefconfig so
that it still honors defaults in x86_64_defconfig?

Thanks,
Song

Re: make olddefconfig surprises

[Nathan Chancellor]

Hi Song,

On Fri, Jan 23, 2026 at 10:21:34AM -0800, Song Liu wrote:
> I was surprised by "make olddefconfig". Reporting here in case this is
> something worth fixing/changing.

Thanks for the write up!

> Here is what I see:
> 
> With make defconfig, CONFIG_DEVTMPFS is enabled:
> 
> $ make defconfig
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> #
> $ grep CONFIG_DEVTMPFS .config
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> # CONFIG_DEVTMPFS_SAFE is not set

Right, as CONFIG_DEVTMPFS is explicitly enabled in x86_64_defconfig:

  $ scripts/config --file arch/x86/configs/x86_64_defconfig -s DEVTMPFS
  y

> But with make olddefconfig and an empty .config file,
> CONFIG_DEVTMPFS is disabled:
> 
> $ echo > .config
> $ make olddefconfig
> #
> # configuration written to .config
> #
> $ grep CONFIG_DEVTMPFS .config
> # CONFIG_DEVTMPFS is not set

The key here is "an empty .config file". olddefconfig is documented in
'make help':

  Same as oldconfig but sets new symbols to their default value without
  prompting

and oldconfig is documented as:

  Update current config utilising a provided .config as base

So if .config is present but empty, all symbols will be new and they
will be set to their default value from its Kconfig definition
(basically just alldefconfig at that point).

> In the meanwhile, CONFIG_DEVTMPFS is enabled in my /proc/config.gz
> and /boot/config*

I think /boot/config-$(uname -r) is only used as a potential
configuration base when no configuration is provided initially but it is
not examined at all for the sake of olddefconfig.

> I checked with a few folks. They were also surprised by this.
> 
> I think the logic of "make olddefconfig" is: With a .config, olddefconfig will
> not look at other defaults (x86_64_defconfig, /proc/config.gz, /boot/config*,
> etc.). Instead, olddefconfig only follows Kconfig files. If a config doesn't
> have "default=y" in Kconfig files, it will be disabled.

Correct, per the "sets new symbols to their default value" from the help
text above.

> This is confusing to users. For example, selftests users often have
> a config file in "tools/testing/selftests/*/config" showing which configs are
> needed for the tests to pass. The expectation is: default config with these
> changes will work. However, this is actually not the case. Many of these
> config files actually have "CONFIG_DEVTMPFS=y" to make it work.

I am a little confused by this and how it relates to olddefconfig? Is
this not just a problem with the config file in the selftests not having
every configuration that is needed if it expects CONFIG_DEVTMPFS=y but
does not have it listed? Or am I missing something else here? How are
those config files in selftests expected to be used? Are they merged
into existing configuration files with scripts/kconfig/merge_config.sh
or are they used as a .config then have olddefconfig run on them?

> So, the question is, shall we change the behavior of olddefconfig so
> that it still honors defaults in x86_64_defconfig?

Perhaps this could be clarified somehow in 'make help' or elsewhere in
the Kconfig documentation but this could be a misunderstanding of the
point of olddefconfig. It is just meant to transition an old/existing
configuration file to the current tree noninteractively. It won't
manipulate a configuration beyond that and I am not sure that it should,
especially since it gets a little confusing around what other
configuration files should be taken into account when changing values.

Cheers,
Nathan

Re: make olddefconfig surprises

[Song Liu]

Hi Nathan,

Thanks for your kind reply!

On Fri, Jan 23, 2026 at 12:54 PM Nathan Chancellor <nathan@kernel.org> wrote:
[...]
> > This is confusing to users. For example, selftests users often have
> > a config file in "tools/testing/selftests/*/config" showing which configs are
> > needed for the tests to pass. The expectation is: default config with these
> > changes will work. However, this is actually not the case. Many of these
> > config files actually have "CONFIG_DEVTMPFS=y" to make it work.
>
> I am a little confused by this and how it relates to olddefconfig? Is
> this not just a problem with the config file in the selftests not having
> every configuration that is needed if it expects CONFIG_DEVTMPFS=y but
> does not have it listed? Or am I missing something else here? How are
> those config files in selftests expected to be used? Are they merged
> into existing configuration files with scripts/kconfig/merge_config.sh
> or are they used as a .config then have olddefconfig run on them?

I think in many cases, we use selftests/xx/config as the base .config
and run olddefconfig on it. This is how I got confused in the first
place.

I guess the right way to achieve the this goal is:
    make defconfig
    ./scripts/kconfig/merge_config.sh .config selftests/xxx/config

Actually, from my simple tests, this is the same as
    make defconfig
    cat  selftests/xxx/config >> .config
    make olddefconfig

It appears merge_config.sh and olddefconfig cannot figure out
dependencies, so we need to do it manually. For example, if I
want CONFIG_LIVEPATCH=y, I also need to include all the
dependencies in selftests/xxx/config:

    CONFIG_FUNCTION_TRACER=y
    CONFIG_DYNAMIC_FTRACE=y
    CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
    CONFIG_LIVEPATCH=y

I haven't figured out a way to include all the dependencies
automatically. Did I miss something?

> > So, the question is, shall we change the behavior of olddefconfig so
> > that it still honors defaults in x86_64_defconfig?
>
> Perhaps this could be clarified somehow in 'make help' or elsewhere in
> the Kconfig documentation but this could be a misunderstanding of the
> point of olddefconfig. It is just meant to transition an old/existing
> configuration file to the current tree noninteractively. It won't
> manipulate a configuration beyond that and I am not sure that it should,
> especially since it gets a little confusing around what other
> configuration files should be taken into account when changing values.

I think we shouldn't change the behavior of olddefconfig. It has a very
valid use case.

Thanks,
Song

Re: make olddefconfig surprises

[Nathan Chancellor]

On Fri, Jan 23, 2026 at 02:54:27PM -0800, Song Liu wrote:
> I think in many cases, we use selftests/xx/config as the base .config
> and run olddefconfig on it. This is how I got confused in the first
> place.

Okay, that makes much more sense in light of everything! I would expect
that to work but only if the dependencies of all the required
configurations are also included in the files.

> I guess the right way to achieve the this goal is:
>     make defconfig
>     ./scripts/kconfig/merge_config.sh .config selftests/xxx/config
> 
> Actually, from my simple tests, this is the same as
>     make defconfig
>     cat  selftests/xxx/config >> .config
>     make olddefconfig

Right, I believe those two are generally equivalent. merge_config.sh
becomes more useful as you have more fragments to merge (one recent use
case for performance improvements to merge_config.sh has over 100
fragments to merge) and helps avoid some "redefined" warnings, IIRC.

> It appears merge_config.sh and olddefconfig cannot figure out
> dependencies, so we need to do it manually. For example, if I
> want CONFIG_LIVEPATCH=y, I also need to include all the
> dependencies in selftests/xxx/config:
> 
>     CONFIG_FUNCTION_TRACER=y
>     CONFIG_DYNAMIC_FTRACE=y
>     CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
>     CONFIG_LIVEPATCH=y

Right, that is exactly the issue here: if certain configurations are
expected to be enabled after these files are used as standalone bases or
merged into other files, these files need to have all of their
dependencies included as well.

> I haven't figured out a way to include all the dependencies
> automatically. Did I miss something?

I do not think something like this exists (maybe a SAT solver? :P), at
least not as part of the kernel tree. This is basically the same thing
as not being able to turn on a configuration in menuconfig until you
have gone through and enabled all of its dependencies. I personally use
menuconfig when trying to create a configuration fragment for minimized
reproducers on top of defconfigs because it is easy to see the final
diff when everything is switched:

  $ make defconfig
  $ make menuconfig
  $ git diff --no-index .config.old .config

You could start with defconfig or a more minimal configuration like
allnoconfig depending on how the selftests config is expected to be
used (as a base or merged into other configs).

Cheers,
Nathan

Re: make olddefconfig surprises

[Song Liu]

On Fri, Jan 23, 2026 at 3:44 PM Nathan Chancellor <nathan@kernel.org> wrote:
[...]
> I do not think something like this exists (maybe a SAT solver? :P), at
> least not as part of the kernel tree. This is basically the same thing
> as not being able to turn on a configuration in menuconfig until you
> have gone through and enabled all of its dependencies. I personally use
> menuconfig when trying to create a configuration fragment for minimized
> reproducers on top of defconfigs because it is easy to see the final
> diff when everything is switched:
>
>   $ make defconfig
>   $ make menuconfig
>   $ git diff --no-index .config.old .config

I also use menuconfig to figure out the dependencies. The problem of
this approach is that, if defconfig changes, specifically, if a dependency
is changed from y to n in defconfig, the fragment may stop working.
IOW, the fragment assumes some dependency is enabled by default,
but there is no guarantee that the dependency will always be y in
defconfig. This should happen rarely though.

I guess figuring out all dependencies is not too difficult? But I guess
the reward is not very big either.

> You could start with defconfig or a more minimal configuration like
> allnoconfig depending on how the selftests config is expected to be
> used (as a base or merged into other configs).

Thanks for sharing these tips.

Song

Re: make olddefconfig surprises

[Nicolas Schier]

On Fri, Jan 23, 2026 at 03:57:59PM -0800, Song Liu wrote:
> On Fri, Jan 23, 2026 at 3:44 PM Nathan Chancellor <nathan@kernel.org> wrote:
> [...]
> > I do not think something like this exists (maybe a SAT solver? :P), at
> > least not as part of the kernel tree. This is basically the same thing
> > as not being able to turn on a configuration in menuconfig until you
> > have gone through and enabled all of its dependencies. I personally use
> > menuconfig when trying to create a configuration fragment for minimized
> > reproducers on top of defconfigs because it is easy to see the final
> > diff when everything is switched:
> >
> >   $ make defconfig
> >   $ make menuconfig
> >   $ git diff --no-index .config.old .config
> 
> I also use menuconfig to figure out the dependencies. The problem of
> this approach is that, if defconfig changes, specifically, if a dependency
> is changed from y to n in defconfig, the fragment may stop working.
> IOW, the fragment assumes some dependency is enabled by default,
> but there is no guarantee that the dependency will always be y in
> defconfig. This should happen rarely though.
> 
> I guess figuring out all dependencies is not too difficult? But I guess
> the reward is not very big either.
> 
> > You could start with defconfig or a more minimal configuration like
> > allnoconfig depending on how the selftests config is expected to be
> > used (as a base or merged into other configs).
> 
> Thanks for sharing these tips.
> 
> Song
> 

Have you tried to use something like

  make KCONFIG_ALLCONFIG=whatever/minimal.config make allnoconfig

?

Kind regards,
Nicolas

Re: make olddefconfig surprises

[Song Liu]

On Sat, Jan 24, 2026 at 11:40 AM Nicolas Schier <nsc@kernel.org> wrote:
[...]
> Have you tried to use something like
>
>   make KCONFIG_ALLCONFIG=whatever/minimal.config make allnoconfig

Hmm.. This doesn't seem to work (or I didn't get it right):

$ cat y.config
CONFIG_LIVEPATCH=y
$ make KCONFIG_ALLCONFIG=y.config allnoconfig
#
# No change to .config
#
$ grep LIVEPATCH .config || echo no LIVEPATCH
no LIVEPATCH

Thanks,
Song

Re: make olddefconfig surprises

[Randy Dunlap]

On 1/26/26 9:17 AM, Song Liu wrote:
> On Sat, Jan 24, 2026 at 11:40 AM Nicolas Schier <nsc@kernel.org> wrote:
> [...]
>> Have you tried to use something like
>>
>>   make KCONFIG_ALLCONFIG=whatever/minimal.config make allnoconfig
> 
> Hmm.. This doesn't seem to work (or I didn't get it right):
> 
> $ cat y.config
> CONFIG_LIVEPATCH=y
> $ make KCONFIG_ALLCONFIG=y.config allnoconfig
> #
> # No change to .config
> #
> $ grep LIVEPATCH .config || echo no LIVEPATCH
> no LIVEPATCH

You still need to supply all of the dependencies.
We don't have an in-tree kernel config tool that will automatically
set all of the dependencies.


-- 
~Randy

Re: make olddefconfig surprises

[Song Liu]

On Mon, Jan 26, 2026 at 9:52 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
>
>
> On 1/26/26 9:17 AM, Song Liu wrote:
> > On Sat, Jan 24, 2026 at 11:40 AM Nicolas Schier <nsc@kernel.org> wrote:
> > [...]
> >> Have you tried to use something like
> >>
> >>   make KCONFIG_ALLCONFIG=whatever/minimal.config make allnoconfig
> >
> > Hmm.. This doesn't seem to work (or I didn't get it right):
> >
> > $ cat y.config
> > CONFIG_LIVEPATCH=y
> > $ make KCONFIG_ALLCONFIG=y.config allnoconfig
> > #
> > # No change to .config
> > #
> > $ grep LIVEPATCH .config || echo no LIVEPATCH
> > no LIVEPATCH
>
> You still need to supply all of the dependencies.
> We don't have an in-tree kernel config tool that will automatically
> set all of the dependencies.

Got it. Thanks for the clarification!

Song