* Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > On Sun, Sep 4, 2022 at 6:48 PM Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > > > > * Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > > > Unfortunately, even without the ARCH=i386 'make savedefconfig' doesn't > > > > seem to be doing the right thing & is dropping the '# CONFIG_64BIT is > > > > not set' line: > > > > > > > > > Oh, really? > > > > > > Without ARCH=i386, it works correctly for me. > > > > > > > > > > > > masahiro@zoe:~/ref/linux$ make i386_defconfig savedefconfig > > > # > > > # No change to .config > > > # > > > masahiro@zoe:~/ref/linux$ grep CONFIG_64BIT defconfig > > > # CONFIG_64BIT is not set > > > > Yeah, so why do these two seemingly identical commands produce two > > different .config's: > > > > $ make ARCH=i386 defconfig > > *** Default configuration is based on 'i386_defconfig' > > > > $ make i386_defconfig > > > > ? > > > > As Nathan explained in this thread, > the prompt of CONFIG_64BIT is hidden > when ARCH=i386. Yeah, so my 'why' question was more about why we'd tolerate the UI inconsistency in seemingly similar commands generating subtly different .config's. In other words, what should we modify in this Kconfig block, or in other parts of the kernel: > config 64BIT > bool "64-bit kernel" if "$(ARCH)" = "x86" > default "$(ARCH)" != "i386" > help > Say yes to build a 64-bit kernel - formerly known as x86_64 > Say no to build a 32-bit kernel - formerly known as i386 ... to not have this Kconfig UI quirk/bug/inconsistency? I hope we agree that the status quo is not ideal. Thanks, Ingo
