Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1650936 > unrolled thread
| Started by | Max Filippov <jcmvbkbc@gmail.com> |
|---|---|
| First post | 2017-05-26 00:30 +0200 |
| Last post | 2017-05-29 15:00 +0200 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) Max Filippov <jcmvbkbc@gmail.com> - 2017-05-26 00:30 +0200
Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) Babu Moger <babu.moger@oracle.com> - 2017-05-26 00:50 +0200
Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) Max Filippov <jcmvbkbc@gmail.com> - 2017-05-26 01:00 +0200
Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) Max Filippov <jcmvbkbc@gmail.com> - 2017-05-26 00:50 +0200
Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) Arnd Bergmann <arnd@arndb.de> - 2017-05-29 15:00 +0200
| From | Max Filippov <jcmvbkbc@gmail.com> |
|---|---|
| Date | 2017-05-26 00:30 +0200 |
| Subject | Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) |
| Message-ID | <tL9qy-5KR-15@gated-at.bofh.it> |
On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: >> I guess the time is ripe for adding (both) symbols to all architectures? > > Good idea. I think we can do most of this by adding a few lines to > arch/Kconfig: > > config CPU_BIG_ENDIAN > bool > > config CPU_LITTLE_ENDIAN > def_bool !CPU_BIG_ENDIAN > > This way, we only need to add 'select CPU_BIG_ENDIAN' to the > architectures that are always big-endian, and we don't need to > change anything for the ones that have a single 'CPU_BIG_ENDIAN' > option. > > The three architectures that have a 'choice' statement (mips, ppc and > sh) will have to convert, and m32r will have to replace the > option with the opposite one, which could break 'make oldconfig', > but nobody really cares about m32r any more. Xtensa may have either endianness and for xtensa we define CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN in the arch/xtensa/Makefile based on the value of the compiler builtin macro. -- Thanks. -- Max
[toc] | [next] | [standalone]
| From | Babu Moger <babu.moger@oracle.com> |
|---|---|
| Date | 2017-05-26 00:50 +0200 |
| Message-ID | <tL9JT-5SC-9@gated-at.bofh.it> |
| In reply to | #1650936 |
On 5/25/2017 5:27 PM, Max Filippov wrote: > On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven >> <geert@linux-m68k.org> wrote: >>> I guess the time is ripe for adding (both) symbols to all architectures? >> Good idea. I think we can do most of this by adding a few lines to >> arch/Kconfig: >> >> config CPU_BIG_ENDIAN >> bool >> >> config CPU_LITTLE_ENDIAN >> def_bool !CPU_BIG_ENDIAN >> >> This way, we only need to add 'select CPU_BIG_ENDIAN' to the >> architectures that are always big-endian, and we don't need to >> change anything for the ones that have a single 'CPU_BIG_ENDIAN' >> option. >> >> The three architectures that have a 'choice' statement (mips, ppc and >> sh) will have to convert, and m32r will have to replace the >> option with the opposite one, which could break 'make oldconfig', >> but nobody really cares about m32r any more. > Xtensa may have either endianness and for xtensa we define > CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN > in the arch/xtensa/Makefile based on the value of the compiler builtin > macro. Hmm.. That means defining CPU_LITTLE_ENDIAN based on "def_bool !CPU_BIG_ENDIAN" will be a problem for Xtensa because menuconfig does not have the knowledge of compiler builtin macro. Is that correct?
[toc] | [prev] | [next] | [standalone]
| From | Max Filippov <jcmvbkbc@gmail.com> |
|---|---|
| Date | 2017-05-26 01:00 +0200 |
| Message-ID | <tL9Tz-5Wn-1@gated-at.bofh.it> |
| In reply to | #1650956 |
On Thu, May 25, 2017 at 3:41 PM, Babu Moger <babu.moger@oracle.com> wrote: > On 5/25/2017 5:27 PM, Max Filippov wrote: >> Xtensa may have either endianness and for xtensa we define >> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN >> in the arch/xtensa/Makefile based on the value of the compiler builtin >> macro. > > Hmm.. That means defining CPU_LITTLE_ENDIAN based on "def_bool > !CPU_BIG_ENDIAN" will > be a problem for Xtensa because menuconfig does not have the knowledge of > compiler builtin macro. > Is that correct? I think so. OTOH outside the arch/ CPU_LITTLE_ENDIAN is only used in two Kconfig files: drivers/crypto/nx/Kconfig drivers/isdn/hisax/Kconfig both of which are irrelevant for xtensa. -- Thanks. -- Max
[toc] | [prev] | [next] | [standalone]
| From | Max Filippov <jcmvbkbc@gmail.com> |
|---|---|
| Date | 2017-05-26 00:50 +0200 |
| Message-ID | <tL9JT-5SC-11@gated-at.bofh.it> |
| In reply to | #1650936 |
On Thu, May 25, 2017 at 3:27 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> I guess the time is ripe for adding (both) symbols to all architectures?
>>
>> Good idea. I think we can do most of this by adding a few lines to
>> arch/Kconfig:
>>
>> config CPU_BIG_ENDIAN
>> bool
>>
>> config CPU_LITTLE_ENDIAN
>> def_bool !CPU_BIG_ENDIAN
>>
>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>> architectures that are always big-endian, and we don't need to
>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>> option.
>>
>> The three architectures that have a 'choice' statement (mips, ppc and
>> sh) will have to convert, and m32r will have to replace the
>> option with the opposite one, which could break 'make oldconfig',
>> but nobody really cares about m32r any more.
>
> Xtensa may have either endianness and for xtensa we define
> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
> in the arch/xtensa/Makefile based on the value of the compiler builtin
> macro.
Also, in outside the Kconfig files there's much more instances of
__{BIG,LITTLE}_ENDIAN than CONFIG_CPU_{BIG,LITTLE}_ENDIAN:
$ git grep '__\(BIG\|LITTLE\)_ENDIAN' | wc -l
4537
$ git grep 'CONFIG_CPU_\(BIG\|LITTLE\)_ENDIAN' | wc -l
247
My understanding is that CONFIG_CPU_{BIG,LITTLE}_ENDIAN was
intended to be used only in Kconfig files, and perhaps all of its uses
outside should be replaced with __{BIG,LITTLE}_ENDIAN.
--
Thanks.
-- Max
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-05-29 15:00 +0200 |
| Message-ID | <tMsr8-8qg-9@gated-at.bofh.it> |
| In reply to | #1650957 |
On Fri, May 26, 2017 at 12:43 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, May 25, 2017 at 3:27 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> I guess the time is ripe for adding (both) symbols to all architectures?
>>>
>>> Good idea. I think we can do most of this by adding a few lines to
>>> arch/Kconfig:
>>>
>>> config CPU_BIG_ENDIAN
>>> bool
>>>
>>> config CPU_LITTLE_ENDIAN
>>> def_bool !CPU_BIG_ENDIAN
>>>
>>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>>> architectures that are always big-endian, and we don't need to
>>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>>> option.
>>>
>>> The three architectures that have a 'choice' statement (mips, ppc and
>>> sh) will have to convert, and m32r will have to replace the
>>> option with the opposite one, which could break 'make oldconfig',
>>> but nobody really cares about m32r any more.
>>
>> Xtensa may have either endianness and for xtensa we define
>> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
>> in the arch/xtensa/Makefile based on the value of the compiler builtin
>> macro.
I can sort of see why xtensa did it the other way round from everyone
else (letting the toolchain decide what the kernel is, rather than letting
the kernel pass the respective flags to gcc), but I'd argue that it would
be better overall for xtensa to change over so we do it consistently
on all architectures.
> Also, in outside the Kconfig files there's much more instances of
> __{BIG,LITTLE}_ENDIAN than CONFIG_CPU_{BIG,LITTLE}_ENDIAN:
>
> $ git grep '__\(BIG\|LITTLE\)_ENDIAN' | wc -l
> 4537
> $ git grep 'CONFIG_CPU_\(BIG\|LITTLE\)_ENDIAN' | wc -l
> 247
>
> My understanding is that CONFIG_CPU_{BIG,LITTLE}_ENDIAN was
> intended to be used only in Kconfig files, and perhaps all of its uses
> outside should be replaced with __{BIG,LITTLE}_ENDIAN.
Right, but I also think that using the CONFIG_CPU_* symbols in
code makes sense because it is less ambiguous: the way we use
__{BIG,LITTLE}_ENDIAN in the kernel is different from how user
space uses them in glibc, and this confuses everyone when they
try to use them in the kernel after being familiar with the traditional
way. The Kconfig symbols don't have this problem.
Arnd
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web