linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH] x86/config: Make the x86 defconfigs a bit more usable
Date: Sun, 4 Sep 2022 11:48:02 +0200	[thread overview]
Message-ID: <YxR0UlS0Jpz9uqb7@gmail.com> (raw)
In-Reply-To: <CAK7LNASyp8SzO3G+th5RgmRNBM_ryKuy0XzaMrdUdo8Sd6RR0A@mail.gmail.com>


* Masahiro Yamada <masahiroy@kernel.org> 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

?

Basically the canonical way to generate a defconfig is to provide an ARCH, 
then use the common 'defconfig' target:

   make ARCH=i386      defconfig
   make ARCH=x86       defconfig
   make ARCH=arm       defconfig
   make ARCH=arm64     defconfig
   make ARCH=powerpc   defconfig
   make ARCH=s390      defconfig
   make ARCH=sparc     defconfig
   make ARCH=sparc64   defconfig
   ...

This is what my build test scripts are using to quick-test cross-arch 
builds. It's a straightforward way to generate defconfigs without knowing 
the details of the myriads of random defconfig targets some architectures 
have, such as:

  kepler:~/tip> ls arch/arm/configs/
  am200epdkit_defconfig     gemini_defconfig         multi_v5_defconfig    s5pv210_defconfig
  aspeed_g4_defconfig       h3600_defconfig          multi_v7_defconfig    sama5_defconfig
  aspeed_g5_defconfig       h5000_defconfig          mv78xx0_defconfig     sama7_defconfig
  assabet_defconfig         hackkit_defconfig        mvebu_v5_defconfig    shannon_defconfig
  at91_dt_defconfig         hisi_defconfig           mvebu_v7_defconfig    shmobile_defconfig
  axm55xx_defconfig         imxrt_defconfig          mxs_defconfig         simpad_defconfig
  badge4_defconfig          imx_v4_v5_defconfig      neponset_defconfig    socfpga_defconfig
  bcm2835_defconfig         imx_v6_v7_defconfig      netwinder_defconfig   sp7021_defconfig
  cerfcube_defconfig        integrator_defconfig     nhk8815_defconfig     spear13xx_defconfig
  clps711x_defconfig        iop32x_defconfig         omap1_defconfig       spear3xx_defconfig
  cm_x300_defconfig         ixp4xx_defconfig         omap2plus_defconfig   spear6xx_defconfig
  cns3420vb_defconfig       jornada720_defconfig     orion5x_defconfig     spitz_defconfig
  colibri_pxa270_defconfig  keystone_defconfig       oxnas_v6_defconfig    stm32_defconfig
  colibri_pxa300_defconfig  lart_defconfig           palmz72_defconfig     sunxi_defconfig
  collie_defconfig          lpc18xx_defconfig        pcm027_defconfig      tct_hammer_defconfig
  corgi_defconfig           lpc32xx_defconfig        pleb_defconfig        tegra_defconfig
  davinci_all_defconfig     lpd270_defconfig         pxa168_defconfig      trizeps4_defconfig
  dove_defconfig            lubbock_defconfig        pxa255-idp_defconfig  u8500_defconfig
  dram_0x00000000.config    magician_defconfig       pxa3xx_defconfig      versatile_defconfig
  dram_0xc0000000.config    mainstone_defconfig      pxa910_defconfig      vexpress_defconfig
  dram_0xd0000000.config    milbeaut_m10v_defconfig  pxa_defconfig         vf610m4_defconfig
  ep93xx_defconfig          mini2440_defconfig       qcom_defconfig        viper_defconfig
  eseries_pxa_defconfig     mmp2_defconfig           realview_defconfig    vt8500_v6_v7_defconfig
  exynos_defconfig          moxart_defconfig         rpc_defconfig         xcep_defconfig
  ezx_defconfig             mps2_defconfig           s3c2410_defconfig     zeus_defconfig
  footbridge_defconfig      multi_v4t_defconfig      s3c6400_defconfig

But this doesn't seem to be working reliably on i386:

  kepler:~/tip> make i386_defconfig
  #
  # configuration written to .config
  #
  kepler:~/tip> /bin/cp .config .config.i386_defconfig.1

  kepler:~/tip> make ARCH=i386 defconfig
  *** Default configuration is based on 'i386_defconfig'
  #
  # configuration written to .config
  #
  kepler:~/tip> /bin/cp .config .config.i386_defconfig.2

  kepler:~/tip> diff -up .config.i386_defconfig.1 .config.i386_defconfig.2
  --- .config.i386_defconfig.1	2022-09-04 11:34:48.253202205 +0200
  +++ .config.i386_defconfig.2	2022-09-04 11:35:04.268758331 +0200
  @@ -1,6 +1,6 @@
   #
   # Automatically generated file; DO NOT EDIT.
  -# Linux/x86 6.0.0-rc3 Kernel Configuration
  +# Linux/i386 6.0.0-rc3 Kernel Configuration
   #
   CONFIG_CC_VERSION_TEXT="gcc (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]"
   CONFIG_CC_IS_GCC=y
  @@ -261,7 +261,6 @@ CONFIG_PROFILING=y
   CONFIG_TRACEPOINTS=y
   # end of General setup
   
  -# CONFIG_64BIT is not set
   CONFIG_X86_32=y
   CONFIG_X86=y
   CONFIG_INSTRUCTION_DECODER=y

Note how in the ARCH=i386 case the build system claims to use i386_defconfig:

  *** Default configuration is based on 'i386_defconfig'

But that doesn't seem to be identical with when we specify i386_defconfig 
directly as a target...

What am I missing?

Thanks,

	Ingo

  reply	other threads:[~2022-09-04  9:48 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 11:11 [GIT PULL] locking changes for v5.18 Ingo Molnar
2022-03-22 22:05 ` Linus Torvalds
2022-03-22 22:19   ` Borislav Petkov
2022-03-22 22:58     ` Linus Torvalds
2022-03-23  7:11       ` Sebastian Andrzej Siewior
2022-03-23 11:09         ` [PATCH] locking/local_lock: Pretend to use the per-CPU variable if not needed Sebastian Andrzej Siewior
2022-03-23 17:17           ` Linus Torvalds
2022-03-24 17:39             ` [PATCH 0/3] Remove volatile from arch_raw_cpu_ptr() and revert the hacks Sebastian Andrzej Siewior
2022-03-24 17:39               ` [PATCH 1/3] x86/percpu: Remove volatile from arch_raw_cpu_ptr() Sebastian Andrzej Siewior
2022-03-24 17:39               ` [PATCH 2/3] Revert "locking/local_lock: Make the empty local_lock_*() function a macro." Sebastian Andrzej Siewior
2022-03-24 17:39               ` [PATCH 3/3] Revert "mm/page_alloc: mark pagesets as __maybe_unused" Sebastian Andrzej Siewior
2022-03-24 18:28               ` [PATCH 0/3] Remove volatile from arch_raw_cpu_ptr() and revert the hacks Linus Torvalds
2022-03-28 13:55                 ` Peter Zijlstra
2022-03-28 14:59                   ` Sebastian Andrzej Siewior
2022-03-28 14:58                 ` [PATCH v2 " Sebastian Andrzej Siewior
2022-03-28 14:58                   ` [PATCH v2 1/3] x86/percpu: Remove volatile from arch_raw_cpu_ptr() Sebastian Andrzej Siewior
2022-04-05  8:28                     ` [tip: locking/urgent] " tip-bot2 for Sebastian Andrzej Siewior
2022-03-28 14:58                   ` [PATCH v2 2/3] Revert "locking/local_lock: Make the empty local_lock_*() function a macro." Sebastian Andrzej Siewior
2022-04-05  8:28                     ` [tip: locking/urgent] " tip-bot2 for Sebastian Andrzej Siewior
2022-03-28 14:58                   ` [PATCH v2 3/3] Revert "mm/page_alloc: mark pagesets as __maybe_unused" Sebastian Andrzej Siewior
2022-04-05  8:28                     ` [tip: locking/urgent] " tip-bot2 for Sebastian Andrzej Siewior
2022-03-23 11:21       ` [PATCH] x86/defconfig: Enable WERROR Borislav Petkov
2022-03-23 17:19         ` Linus Torvalds
2022-03-23 17:33           ` Borislav Petkov
2022-03-24  8:31           ` [PATCH] x86/config: Make the x86 defconfigs a bit more usable Ingo Molnar
2022-03-24  9:12             ` David Laight
2022-03-24 15:47             ` Nathan Chancellor
2022-03-25 11:52               ` Andy Shevchenko
2022-03-27 19:04                 ` Ingo Molnar
2022-03-27 19:03               ` Ingo Molnar
2022-03-28 15:41                 ` Nathan Chancellor
2022-09-02  8:50                   ` Ingo Molnar
2022-09-02  9:18                     ` Masahiro Yamada
2022-09-04  9:48                       ` Ingo Molnar [this message]
2022-09-05  2:16                         ` Masahiro Yamada
2022-09-05  9:54                           ` Ingo Molnar
     [not found]                             ` <CAK7LNAQyiNpbLuVjjQ8-GOQECtfQZqsNS8xH0E2ZkLAHYtXt7A@mail.gmail.com>
2022-09-10 17:28                               ` Linus Torvalds
2022-03-24  8:16         ` [tip: x86/urgent] x86/defconfig: Enable WERROR tip-bot2 for Borislav Petkov
2022-03-25 11:41       ` [GIT PULL] locking changes for v5.18 Andy Shevchenko
2022-03-25 12:23         ` Peter Zijlstra
2022-03-25 13:06           ` Andy Shevchenko
2022-03-25 17:29         ` Linus Torvalds
2022-03-25 17:53           ` Andy Shevchenko
2022-03-22 22:38   ` Peter Zijlstra
2022-03-22 23:26   ` Linus Torvalds
2022-03-24  8:40     ` Ingo Molnar
2022-03-24 10:19       ` Borislav Petkov
2022-03-24 23:19         ` Nick Desaulniers
2022-03-22 23:27 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YxR0UlS0Jpz9uqb7@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=boqun.feng@gmail.com \
    --cc=bp@alien8.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).