| Message ID | 20190926193030.5843-5-anders.roxell@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: defconfig: set/unset for allmodconfig | expand |
On 26/09/2019 20:30, Anders Roxell wrote: > When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig > CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most > people wants. Today allmodconfig does not enable CONFIG_ACPI due to BE config, which is quite unfortunate, I'd say. > > Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so defconfig > it doesn't get enabled when building allmodconfig kernels. When doing a > 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. So without having to pass KCONFIG_ALLCONFIG or do anything else, what about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if that was omitted for a specific reason. Thanks, John > > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 878f379d8d84..c9aa6b9ee996 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y > # CONFIG_SCHED_DEBUG is not set > CONFIG_MEMTEST=y > # CONFIG_CMDLINE_FORCE is not set > +# CONFIG_CPU_BIG_ENDIAN is not set >
On Tue, 1 Oct 2019 at 16:04, John Garry <john.garry@huawei.com> wrote: > > On 26/09/2019 20:30, Anders Roxell wrote: > > When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig > > CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most > > people wants. > > Today allmodconfig does not enable CONFIG_ACPI due to BE config, which > is quite unfortunate, I'd say. right. > > > > > Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so > > defconfig thanks. > > > it doesn't get enabled when building allmodconfig kernels. When doing a > > 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. > > So without having to pass KCONFIG_ALLCONFIG or do anything else, what > about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if > that was omitted for a specific reason. Oh, I tried to elaborate on the idea in the cover letter, that using the defconfig as base and then configure the rest as modules is to get a bootable kernel that have as many features turned on as possible. That will make it possible to run as wide a range of testsuites as possible on a single kernel. Does that make it clearer ? Cheers, Anders > > Thanks, > John > > > > > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > > --- > > arch/arm64/configs/defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > index 878f379d8d84..c9aa6b9ee996 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y > > # CONFIG_SCHED_DEBUG is not set > > CONFIG_MEMTEST=y > > # CONFIG_CMDLINE_FORCE is not set > > +# CONFIG_CPU_BIG_ENDIAN is not set > > > >
On 03/10/2019 08:40, Anders Roxell wrote: > On Tue, 1 Oct 2019 at 16:04, John Garry <john.garry@huawei.com> wrote: >> >> On 26/09/2019 20:30, Anders Roxell wrote: >>> When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig >>> CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most >>> people wants. >> >> Today allmodconfig does not enable CONFIG_ACPI due to BE config, which >> is quite unfortunate, I'd say. > > right. > >> >>> >>> Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so >> >> defconfig > > thanks. > >> >>> it doesn't get enabled when building allmodconfig kernels. When doing a >>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. >> >> So without having to pass KCONFIG_ALLCONFIG or do anything else, what >> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if >> that was omitted for a specific reason. > > Oh, I tried to elaborate on the idea in the cover letter, that using > the defconfig > as base and then configure the rest as modules is to get a bootable kernel > that have as many features turned on as possible. That will make it possible > to run as wide a range of testsuites as possible on a single kernel. > > Does that make it clearer ? Hi Anders, Yeah, I got the idea. So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped", I don't know what the rules are in terms of resyncing the common defconfig (I was under the impression that it's done per release cycle by the arm soc maintainers, but can't find evidence as such), but your change may be easily lost in this way. Thanks, John > > Cheers, > Anders > > >> >> Thanks, >> John >> >>> >>> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> >>> --- >>> arch/arm64/configs/defconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >>> index 878f379d8d84..c9aa6b9ee996 100644 >>> --- a/arch/arm64/configs/defconfig >>> +++ b/arch/arm64/configs/defconfig >>> @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y >>> # CONFIG_SCHED_DEBUG is not set >>> CONFIG_MEMTEST=y >>> # CONFIG_CMDLINE_FORCE is not set >>> +# CONFIG_CPU_BIG_ENDIAN is not set >>> >> >> > > . >
On Thu, Oct 3, 2019 at 1:15 PM John Garry <john.garry@huawei.com> wrote: > On 03/10/2019 08:40, Anders Roxell wrote: > > On Tue, 1 Oct 2019 at 16:04, John Garry <john.garry@huawei.com> wrote: > >> On 26/09/2019 20:30, Anders Roxell wrote: > >>> it doesn't get enabled when building allmodconfig kernels. When doing a > >>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. > >> > >> So without having to pass KCONFIG_ALLCONFIG or do anything else, what > >> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if > >> that was omitted for a specific reason. > > > > Oh, I tried to elaborate on the idea in the cover letter, that using > > the defconfig > > as base and then configure the rest as modules is to get a bootable kernel > > that have as many features turned on as possible. That will make it possible > > to run as wide a range of testsuites as possible on a single kernel. > > > > Does that make it clearer ? > > Hi Anders, > > Yeah, I got the idea. > > So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be > dropped", I don't know what the rules are in terms of resyncing the > common defconfig (I was under the impression that it's done per release > cycle by the arm soc maintainers, but can't find evidence as such), but > your change may be easily lost in this way. We don't do it every release, but occasionally someone sends a patch with a refresh, and this might easily get missed. We could force the allmodconfig kernel to be little-endian by default, using a choice statement to pick endianess like arch/mips and arch/sh do, the effect would be that an allmodconfig kernel gains a few more options that depend on !BIG_ENDIAN, but we would no longer catch a class of endianess bugs in drivers that we otherwise get warnings for. No idea what is better here. Arnd
On Fri, Oct 11, 2019 at 12:25:29PM +0200, Arnd Bergmann wrote: > On Thu, Oct 3, 2019 at 1:15 PM John Garry <john.garry@huawei.com> wrote: > > On 03/10/2019 08:40, Anders Roxell wrote: > > > On Tue, 1 Oct 2019 at 16:04, John Garry <john.garry@huawei.com> wrote: > > >> On 26/09/2019 20:30, Anders Roxell wrote: > > >>> it doesn't get enabled when building allmodconfig kernels. When doing a > > >>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. > > >> > > >> So without having to pass KCONFIG_ALLCONFIG or do anything else, what > > >> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if > > >> that was omitted for a specific reason. > > > > > > Oh, I tried to elaborate on the idea in the cover letter, that using > > > the defconfig > > > as base and then configure the rest as modules is to get a bootable kernel > > > that have as many features turned on as possible. That will make it possible > > > to run as wide a range of testsuites as possible on a single kernel. > > > > > > Does that make it clearer ? > > > > Hi Anders, > > > > Yeah, I got the idea. > > > > So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be > > dropped", I don't know what the rules are in terms of resyncing the > > common defconfig (I was under the impression that it's done per release > > cycle by the arm soc maintainers, but can't find evidence as such), but > > your change may be easily lost in this way. > > We don't do it every release, but occasionally someone sends a patch > with a refresh, and this might easily get missed. > > We could force the allmodconfig kernel to be little-endian by default, > using a choice statement to pick endianess like arch/mips and arch/sh > do, the effect would be that an allmodconfig kernel gains a few more > options that depend on !BIG_ENDIAN, but we would no longer catch > a class of endianess bugs in drivers that we otherwise get warnings > for. No idea what is better here. Does anybody use BIG_ENDIAN? If we're not even building it then maybe we should get rid of it altogether on arm64. I don't know of any supported userspace that supports it or any CPUs that are unable to run little-endian binaries. Will
On Fri, Oct 11, 2019 at 11:27:48AM +0100, Will Deacon wrote: > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we > should get rid of it altogether on arm64. I don't know of any supported > userspace that supports it or any CPUs that are unable to run little-endian > binaries. 32-bit ARM experience is that telco class users really like big endian.
On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Fri, Oct 11, 2019 at 11:27:48AM +0100, Will Deacon wrote: > > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we > > should get rid of it altogether on arm64. I don't know of any supported > > userspace that supports it or any CPUs that are unable to run little-endian > > binaries. So far, all 'allmodconfig' builds are big-endian and have been that way since the option was first added, so build coverage is something we have plenty of. It's also covered by randconfig testing, regardless of the default endianess. > 32-bit ARM experience is that telco class users really like big > endian. Right, basically anyone with a large code base migrated over from a big-endian MIPS or PowerPC legacy that found it cheaper to change the rest of the world than to fix their own code. The only other example of this I heard of besides networking was from banking, where they looked at moving from AIX on PowerPC to Linux on something cheaper, but IIRC they ended up going with LE after all because of the lack of distro support. Whether any users remain in use at this time, I don't know. As most of the larger machines require UEFI to boot, they are currently limited to little-endian for all practical purposes, and smaller embedded machines tend to have a smaller amount of legacy code and are easier to move over to little-endian. One recent reference I could find is specifically for the NXP Layerscape LS1043 in https://www.nxp.com/docs/en/application-note/AN5129.pdf which apparently has some support in their codewarrior tools for big-endian binaries. There are also some recent openembedded bugfixes for big-endian arm64 from NXP: https://www.mail-archive.com/meta-freescale@yoctoproject.org/msg22378.html Adding Chungrong Guo to Cc for additional insight on whether they expect any notable big-endian users in the future. Arnd
On 2019/10/11 18:27, Will Deacon wrote: [...] > > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we > should get rid of it altogether on arm64. I don't know of any supported > userspace that supports it or any CPUs that are unable to run little-endian > binaries. FWIW, massive telecommunication products (based on ARM64) form Huawei are using BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well. Thanks Hanjun
On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <guohanjun@huawei.com> wrote: > > On 2019/10/11 18:27, Will Deacon wrote: > [...] > > > > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we > > should get rid of it altogether on arm64. I don't know of any supported > > userspace that supports it or any CPUs that are unable to run little-endian > > binaries. > > FWIW, massive telecommunication products (based on ARM64) form Huawei are using > BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well. Ok, thanks for the information -- that definitely makes it clear that it cannot go away anytime soon (though it doesn't stop us from change the allmodconfig default if we decide that's a good idea). Do you know if there are currently any patches against mainline to make big-endian work in products, or is everything working out of the box? Arnd
On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote: > On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > 32-bit ARM experience is that telco class users really like big > > endian. > > Right, basically anyone with a large code base migrated over from a > big-endian MIPS or PowerPC legacy that found it cheaper to change > the rest of the world than to fix their own code. I think you need to step off your soap box! Big endian isn't going away, and it likely has nothing to do with code bases. Just look at networking and telco protocols. Everything in that world tends to be big endian. BE is what is understood in that world, and there's little we can do to change it. Demanding that they switch to LE is tantamount to you demanding that their entire world change - it ain't going to happen.
Hi Arnd, On 2019/10/12 22:05, Arnd Bergmann wrote: > On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <guohanjun@huawei.com> wrote: >> >> On 2019/10/11 18:27, Will Deacon wrote: >> [...] >>> >>> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we >>> should get rid of it altogether on arm64. I don't know of any supported >>> userspace that supports it or any CPUs that are unable to run little-endian >>> binaries. >> >> FWIW, massive telecommunication products (based on ARM64) form Huawei are using >> BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well. > > Ok, thanks for the information -- that definitely makes it clear that > it cannot go > away anytime soon (though it doesn't stop us from change the > allmodconfig default > if we decide that's a good idea). I agree with you. > > Do you know if there are currently any patches against mainline to > make big-endian > work in products, or is everything working out of the box? We are not using mainline kernel for product, but LTS 4.4 is working fine, and also we tested LTS 4.19 kernel without any other big-endian patches, the latest big-endian bug we found is this: a6002ec5a8c6 arm64: opcodes.h: Add arm big-endian config options before including arm header The running kernel code covered but Huawei's telecommunication products is limited, but I think ARM64 arch code is working fine for big-endian. Thanks Hanjun
On Sat, Oct 12, 2019 at 04:05:57PM +0200, Arnd Bergmann wrote: > On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <guohanjun@huawei.com> wrote: > > > > On 2019/10/11 18:27, Will Deacon wrote: > > [...] > > > > > > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we > > > should get rid of it altogether on arm64. I don't know of any supported > > > userspace that supports it or any CPUs that are unable to run little-endian > > > binaries. > > > > FWIW, massive telecommunication products (based on ARM64) form Huawei are using > > BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well. > > Ok, thanks for the information -- that definitely makes it clear that > it cannot go > away anytime soon (though it doesn't stop us from change the > allmodconfig default > if we decide that's a good idea). Agreed on both counts. > Do you know if there are currently any patches against mainline to > make big-endian > work in products, or is everything working out of the box? I suspect "everything" is probably much narrower in scope than for little-endian configurations simply because of the lack of distribution support and associated testing. If the companies using it are willing to contribute back fixes as they run into problems, then that's probably the best we can hope for. Will
On Sat, Oct 12, 2019 at 03:50:55PM +0100, Russell King - ARM Linux admin wrote: > On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote: > > On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > > > 32-bit ARM experience is that telco class users really like big > > > endian. > > > > Right, basically anyone with a large code base migrated over from a > > big-endian MIPS or PowerPC legacy that found it cheaper to change > > the rest of the world than to fix their own code. > > I think you need to step off your soap box! Big endian isn't going > away, and it likely has nothing to do with code bases. Just look at > networking and telco protocols. Everything in that world tends to > be big endian. BE is what is understood in that world, and there's > little we can do to change it. > > Demanding that they switch to LE is tantamount to you demanding that > their entire world change - it ain't going to happen. Oh, I wasn't demanding anything! Just interested to know if big-endian is actually being used because it's not something that I'm able to test sensibly and I haven't see anywhere near the amount of (public) effort to keep it supported as for little-endian. However, having asked the question, it's clear that it does have some users so we'll keep maintaining it on a best-effort basis and rely on those users to let us know if anything breaks. Will
On 2019/10/15 0:24, Will Deacon wrote: > On Sat, Oct 12, 2019 at 03:50:55PM +0100, Russell King - ARM Linux admin wrote: >> On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote: >>> On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin >>> <linux@armlinux.org.uk> wrote: >>>> 32-bit ARM experience is that telco class users really like big >>>> endian. >>> >>> Right, basically anyone with a large code base migrated over from a >>> big-endian MIPS or PowerPC legacy that found it cheaper to change >>> the rest of the world than to fix their own code. >> >> I think you need to step off your soap box! Big endian isn't going >> away, and it likely has nothing to do with code bases. Just look at >> networking and telco protocols. Everything in that world tends to >> be big endian. BE is what is understood in that world, and there's >> little we can do to change it. >> >> Demanding that they switch to LE is tantamount to you demanding that >> their entire world change - it ain't going to happen. > > Oh, I wasn't demanding anything! Just interested to know if big-endian is > actually being used because it's not something that I'm able to test > sensibly and I haven't see anywhere near the amount of (public) effort to > keep it supported as for little-endian. However, having asked the question, > it's clear that it does have some users so we'll keep maintaining it on a > best-effort basis and rely on those users to let us know if anything breaks. Sure, we (Huawei kernel team) did that and we will do that in the future as well. Thanks Hanjun
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 878f379d8d84..c9aa6b9ee996 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y # CONFIG_SCHED_DEBUG is not set CONFIG_MEMTEST=y # CONFIG_CMDLINE_FORCE is not set +# CONFIG_CPU_BIG_ENDIAN is not set
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most people wants. Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so it doesn't get enabled when building allmodconfig kernels. When doing a 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)