* + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree
@ 2020-08-20 21:29 akpm
2020-08-21 17:22 ` make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree) Alexey Dobriyan
0 siblings, 1 reply; 4+ messages in thread
From: akpm @ 2020-08-20 21:29 UTC (permalink / raw
To: daniel.diaz, mm-commits, rdunlap, sedat.dilek
The patch titled
Subject: x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig
has been added to the -mm tree. Its filename is
x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Díaz <daniel.diaz@linaro.org>
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
This was found with weird compiler errors on OpenEmbedded
builds, as the compiler was unable to cope with 64-bits data
types:
NOTE: make -j1 bzImage CC=i686-linaro-linux-gcc -fuse-ld=bfd -fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0=/usr/src/debug/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0 -fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot= -fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot-native= -fdebug-prefix-map=/oe/build/tmp/work-shared/intel-core2-32/kernel-source=/usr/src/kernel -ffile-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/git=/kernel-source/ LD=i686-linaro-linux-ld.bfd
GEN Makefile
CC scripts/mod/empty.o
cc1: error: code model 'kernel' not supported in the 32 bit mode
cc1: sorry, unimplemented: 64-bit mode not compiled in
/oe/build/tmp/work-shared/intel-core2-32/kernel-source/scripts/Makefile.build:280: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
/oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:1174: recipe for target 'prepare0' failed
make[1]: *** [prepare0] Error 2
/oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:185: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Link: https://lkml.kernel.org/r/20200819173225.3821449-1-daniel.diaz@linaro.org
Fixes: 1d0e12fd3a84 ("x86/defconfigs: Refresh defconfig files")
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/configs/i386_defconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/configs/i386_defconfig~x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig
+++ a/arch/x86/configs/i386_defconfig
@@ -19,6 +19,7 @@ CONFIG_CGROUP_CPUACCT=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_COMPAT_BRK is not set
CONFIG_PROFILING=y
+# CONFIG_64BIT is not set
CONFIG_SMP=y
CONFIG_X86_GENERIC=y
CONFIG_HPET_TIMER=y
_
Patches currently in -mm which might be from daniel.diaz@linaro.org are
x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch
^ permalink raw reply [flat|nested] 4+ messages in thread
* make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree)
2020-08-20 21:29 + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree akpm
@ 2020-08-21 17:22 ` Alexey Dobriyan
2020-08-21 17:27 ` Randy Dunlap
0 siblings, 1 reply; 4+ messages in thread
From: Alexey Dobriyan @ 2020-08-21 17:22 UTC (permalink / raw
To: linux-kernel; +Cc: daniel.diaz, linux-kernel, rdunlap, sedat.dilek
On Thu, Aug 20, 2020 at 02:29:40PM -0700, akpm@linux-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 |
+---------------------------------------+
The reason is that long ago ARCH was deduced from bitness of the system
make was run on, so that
make allnoconfig
gave 32-bit config on 32-but system and 64-bit on 64-bit system which is
natural thing to do.
During i386/x86_64 merge CONFIG_64BIT became user visible option!
" make allnoconfig" started giving 32-bit config even on x86_64 and 64-bit
defconfig and allmodconfig which it does to this day.
Always passing ARCH is the only way to maintain sanity. I have shell
alias to always pass ARCH=x86_64 so that bitness is both deterministic
and can be overridden.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree)
2020-08-21 17:22 ` make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree) Alexey Dobriyan
@ 2020-08-21 17:27 ` Randy Dunlap
2020-08-21 18:52 ` Sedat Dilek
0 siblings, 1 reply; 4+ messages in thread
From: Randy Dunlap @ 2020-08-21 17:27 UTC (permalink / raw
To: Alexey Dobriyan, linux-kernel; +Cc: daniel.diaz, sedat.dilek
On 8/21/20 10:22 AM, Alexey Dobriyan wrote:
> On Thu, Aug 20, 2020 at 02:29:40PM -0700, akpm@linux-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.
--
~Randy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree)
2020-08-21 17:27 ` Randy Dunlap
@ 2020-08-21 18:52 ` Sedat Dilek
0 siblings, 0 replies; 4+ messages in thread
From: Sedat Dilek @ 2020-08-21 18:52 UTC (permalink / raw
To: Randy Dunlap; +Cc: Alexey Dobriyan, linux-kernel, daniel.diaz
On Fri, Aug 21, 2020 at 7:27 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 8/21/20 10:22 AM, Alexey Dobriyan wrote:
> > On Thu, Aug 20, 2020 at 02:29:40PM -0700, akpm@linux-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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-08-21 18:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-20 21:29 + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree akpm
2020-08-21 17:22 ` make defconfig (Re: + x86-defconfigs-explicitly-unset-config_64bit-in-i386_defconfig.patch added to -mm tree) Alexey Dobriyan
2020-08-21 17:27 ` Randy Dunlap
2020-08-21 18:52 ` Sedat Dilek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.