[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+icZUVPjw_JMXFA9Y=wUewq6Bi0ATFOX-4dce3mOpVbv9SHXw@mail.gmail.com>
Date: Fri, 21 Aug 2020 20:52:17 +0200
From: Sedat Dilek <sedat.dilek@...il.com>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
linux-kernel@...r.kernel.org, daniel.diaz@...aro.org
Subject: Re: make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch
added to -mm tree)
On Fri, Aug 21, 2020 at 7:27 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>
> On 8/21/20 10:22 AM, Alexey Dobriyan wrote:
> > On Thu, Aug 20, 2020 at 02:29:40PM -0700, akpm@...ux-foundation.org wrote:
> >> Subject: x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig
> >>
> >> A recent refresh of the defconfigs got rid of the following (unset)
> >> config:
> >>
> >> # CONFIG_64BIT is not set
> >>
> >> Innocuous as it seems, when the config file is saved again the
> >> behavior is changed so that CONFIG_64BIT=y.
> >>
> >> Currently,
> >>
> >> $ make i386_defconfig
> >> $ grep CONFIG_64BIT .config
> >> CONFIG_64BIT=y
> >>
> >> whereas previously (and with this patch):
> >>
> >> $ make i386_defconfig
> >> $ grep CONFIG_64BIT .config
> >> # CONFIG_64BIT is not set
> >
> > It is highly, highly, highly advisable to always pass ARCH when dealing
> > with 32/64-bit archs:
> >
> > +---------------------------------------+
> > | make ARCH=x86_64 defconfig |
> > | make ARCH=i386 defconfig |
> > +---------------------------------------+
>
> I certainly always do that and I also avoid
> ARCH=x86
> although it is supported/allowed.
>
Unsure, if this already documented - if not - might be good to document it.
While playing with ClangBuiltLinux issue #194 this was not clear to me.
- Sedat -
[1] https://github.com/ClangBuiltLinux/linux/issues/194
[2] https://github.com/ClangBuiltLinux/linux/issues/194#issuecomment-662433916
[3] https://github.com/ClangBuiltLinux/linux/issues/194#issuecomment-662613396
[4] https://github.com/ClangBuiltLinux/linux/issues/194#issuecomment-662620461
Powered by blists - more mailing lists