[3/3] arm64: configs: unset CPU_BIG_ENDIAN

Message ID 20190926193030.5843-5-anders.roxell@linaro.org
State New
Headers show
Series
  • arm64: defconfig: set/unset for allmodconfig
Related show

Commit Message

Anders Roxell Sept. 26, 2019, 7:30 p.m.
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(+)

-- 
2.20.1

Comments

John Garry Oct. 1, 2019, 2:04 p.m. | #1
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

>
Anders Roxell Oct. 3, 2019, 7:40 a.m. | #2
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

> >

>

>
John Garry Oct. 3, 2019, 11:15 a.m. | #3
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

>>>

>>

>>

>

> .

>
Arnd Bergmann Oct. 11, 2019, 10:25 a.m. | #4
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
Will Deacon Oct. 11, 2019, 10:27 a.m. | #5
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
Russell King - ARM Linux admin Oct. 11, 2019, 10:33 a.m. | #6
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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Arnd Bergmann Oct. 11, 2019, 10:47 p.m. | #7
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
Hanjun Guo Oct. 12, 2019, 7:33 a.m. | #8
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
Arnd Bergmann Oct. 12, 2019, 2:05 p.m. | #9
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
Russell King - ARM Linux admin Oct. 12, 2019, 2:50 p.m. | #10
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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Hanjun Guo Oct. 14, 2019, 6:12 a.m. | #11
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
Will Deacon Oct. 14, 2019, 4:20 p.m. | #12
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
Will Deacon Oct. 14, 2019, 4:24 p.m. | #13
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
Hanjun Guo Oct. 15, 2019, 3:13 a.m. | #14
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

Patch

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