All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
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 16:55:38 +0200	[thread overview]
Message-ID: <20190412145538.GA24473@lst.de> (raw)
In-Reply-To: <CAK8P3a2bg9YkbNpAb9uZkXLFZ3juCmmbF7cRw+Dm9ZiLFno2OQ@mail.gmail.com>

On Fri, Apr 12, 2019 at 04:53:28PM +0200, Arnd Bergmann wrote:
> 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:

I'm personally not worried at all. Just trying to respond to Nicks
review comment and make it reasonable generic if we have to have these
checks at all.  I personally would be ok without them, I just don't
want them hidden somewhere in the RISC-V code (RISC-V is always little
endian at least right now).

  reply	other threads:[~2019-04-12 14:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 14:35 [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess Christoph Hellwig
2019-04-12 14:53 ` Arnd Bergmann
2019-04-12 14:55   ` Christoph Hellwig [this message]
2019-04-12 15:22     ` Arnd Bergmann
2019-04-12 16:05   ` Nick Kossifidis
2019-05-10 10:53     ` Dmitry Vyukov
2019-05-11  0:51       ` Arnd Bergmann
2019-05-11  0:51         ` Arnd Bergmann
2019-05-13  7:39         ` Dmitry Vyukov
2019-05-13  7:39           ` Dmitry Vyukov
2019-05-13 11:33           ` Michael Ellerman
2019-05-13 11:33             ` Michael Ellerman
2019-05-13 11:50             ` Dmitry Vyukov
2019-05-13 11:50               ` Dmitry Vyukov
2019-05-13 12:04               ` Christoph Hellwig
2019-05-13 12:04                 ` Christoph Hellwig
2019-05-15  6:53                 ` Arnd Bergmann
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=20190412145538.GA24473@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mick@ics.forth.gr \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.