ulfalizer/Kconfiglib

.config written by Kconfiglib differs from the one written by the kernel's Kconfig

simonvanderveldt opened this issue · 4 comments

simonvanderveldt commented

First of all thanks for this library! Really liking it so far!

I have a question/issue, couldn't find an existing issue for it.
When using either defconfig or olddefconfig the resulting .config file is different compared to the one generated by the kernel's make (old)defconfig.

The example below is about olddefconfig, but the same happens with defconfig (and possibly others as well, it seems to be a shared thing).

When I run the code from https://github.com/ulfalizer/Kconfiglib/blob/424d0d38e7be15c52fae761a0a98028c4e13212d/olddefconfig.py in a kernel checkout, the generated .config is different compared to when I run make olddefconfig.
It's pretty easy to reproduce:

cd <kernel sources location>
# Make sure we start from a clean slate
rm .config*
# Run Kconfiglib's olddefconfig
ARCH=x86 SRCARCH=x86 olddefconfig
...
bunch of output, resulting config gets written to `.config`
...
mv .config config-kconfiglib
# Run kernel's make olddefconfig
make olddefconfig
# Diff the two
diff .config config-kconfiglib

From a quick look at the diff it seems like the output differs because of:

  • Missing the "header"
-#
-# Automatically generated file; DO NOT EDIT.
-# Linux/x86 4.9.203-gentoo Kernel Configuration
-#
  • Some <FOO> not set lines are not included, for example -# CONFIG_TASKS_RCU is not set
    There are other <BAR> not set lines in the config generated by Kconfiglib, so it's not like all of the "not set" lines are excluded.
  • Additional end of section comments, for example +# end of IRQ subsystem

Are these known issues? Or are they meant to be like this?

ulfalizer commented

Hello,

I think you're running an old kernel.

The extra # FOO is not set lines are probably due to missing this patch that I made to the C tools. The # end of FOO comments were added recently to the C tools too.

Kconfiglib doesn't emulate the header from the C tools (and the test suite strips it before comparing files). Headers can be customized in Kconfiglib by setting the environment variables KCONFIG_CONFIG_HEADER (for .config files) and KCONFIG_AUTOHEADER_HEADER (for generated header files). See the help text for genconfig.py for more information.

The output differences are just cosmetic at least. Kconfiglib will work fine on older Linux kernels too.

Cheers

  • 👍1
ulfalizer commented

Ah, yeah, says 4.9 right there in the header. That's the issue.

Don't worry about the output differences. Will still work fine. You're just getting the improved output that later versions of the C tools would generate too.

simonvanderveldt commented

Clear, thanks for the explanation!

Was already wondering if it might be caused by the old kernel version. I'll be able to try a newer kernel soon, but I'm going to assume it's fine and close this issue in the meantime :) If I still notice some differences on 5.4 I'll reopen if that's OK?

P.S. I have something else that's more of a question than an issue, is it OK if I create an issue for that as well?

ulfalizer commented

Was already wondering if it might be caused by the old kernel version. I'll be able to try a newer kernel soon, but I'm going to assume it's fine and close this issue in the meantime :) If I still notice some differences on 5.4 I'll reopen if that's OK?

Yup, there should never be any differences on the most recent linux-next kernel (besides the header).

P.S. I have something else that's more of a question than an issue, is it OK if I create an issue for that as well?

Could open an issue for it, or ask in the #kconfiglib channel on the Zephyr Slack server. Zephyr is my day job, and I do a bunch of Kconfig stuff there.

  • 👍1