LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nick Kossifidis <mick@ics.forth.gr>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	mick@ics.forth.gr,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
Date: Fri, 12 Apr 2019 19:05:33 +0300	[thread overview]
Message-ID: <fd59e6e22594f740eaf86abad76ee04d@mailhost.ics.forth.gr> (raw)
In-Reply-To: <CAK8P3a2bg9YkbNpAb9uZkXLFZ3juCmmbF7cRw+Dm9ZiLFno2OQ@mail.gmail.com>

Στις 2019-04-12 17:53, Arnd Bergmann έγραψε:
> On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
>> 
>> When removing some dead big endian checks in the RISC-V code Nick
>> suggested that we should have some generic sanity checks.  I don't 
>> think
>> we should have thos inside the RISC-V code, but maybe it might make
>> sense to have these in the generic byteorder headers.  Note that these
>> are UAPI headers and some compilers might not actually define
>> __BYTE_ORDER__, so we first check that it actually exists.
>> 
>> Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Extra checking like this is good in general, but I'm not sure I see
> exactly what kind of issue one might expect to prevent with this:
> 
> All architecture asm/byteorder.h headers either include the only
> possible option, or they check the compiler defined macros:
> 
> arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
> arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
> arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
> arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
> arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
> arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
> arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
> arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
> 
> Are you worried about toolchains that define those differently
> from what these headers expect? Did you encounter such a case?
> 
>       Arnd

The following architectures just include the header file without
checking for any compiler macro:

alpha: little_endian.h
csky: little_endian.h
h8300: big_endian.h
hexagon: little_endian.h
ia64: little_endian.h
m68k: big_endian.h
nios2: little_endian.h
openrisc: big_endian.h
parisc: big_endian.h
riscv: little_endian.h
s390: big_endian.h
sparc: big_endian.h
unicore32: little_endian.h
x86: little_endian.h

Of those who do check for a compiler macro, they don't use the
generic macros (__ORDER_*_ENDIAN__) but arch-specific ones.

Only two architectures (mips and xtensa) that support both big
and little endian return an error in case the endianess can't be
determined, the rest will move on without including any
of *_endian.h files.

I think it's good to have a sanity check in-place for consistency.

Regards,
Nick

  parent reply	other threads:[~2019-04-12 16:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 14:35 Christoph Hellwig
2019-04-12 14:53 ` Arnd Bergmann
2019-04-12 14:55   ` Christoph Hellwig
2019-04-12 15:22     ` Arnd Bergmann
2019-04-12 16:05   ` Nick Kossifidis [this message]
2019-05-10 10:53     ` Dmitry Vyukov
2019-05-11  0:51       ` Arnd Bergmann
2019-05-13  7:39         ` Dmitry Vyukov
2019-05-13 11:33           ` Michael Ellerman
2019-05-13 11:50             ` Dmitry Vyukov
2019-05-13 12:04               ` Christoph Hellwig
2019-05-15  6:53                 ` Arnd Bergmann
2019-05-30  1:46 ` Maciej Rozycki
2019-05-30  6:41   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd59e6e22594f740eaf86abad76ee04d@mailhost.ics.forth.gr \
    --to=mick@ics.forth.gr \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=hch@lst.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).