All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Boaz Harrosh <bharrosh@panasas.com>
Subject: Re: [PATCH 1/2] byteorder: add load/store_{endian} API
Date: Mon, 02 Mar 2009 16:25:44 -0800	[thread overview]
Message-ID: <1236039944.5756.19.camel@brick> (raw)
In-Reply-To: <alpine.LFD.2.00.0903021613590.3111@localhost.localdomain>

On Mon, 2009-03-02 at 16:15 -0800, Linus Torvalds wrote:
> 
> On Mon, 2 Mar 2009, Harvey Harrison wrote:
> > 
> > store_le16 is a new API and is added to be symmetric with the unaligned
> > functions.
> 
> This seems to be expressly designed to be unsafe, in that it casts the 
> thing to the right type, making it impossible for sparse to warn about 
> bad byteorder use.
> 

Unfortunately yes, hopefully you have a solution for the problem I ran
into with this part:

This was added to be symmetric with the unaligned store API, and replace
code doing

*(__le16 *)ptr = cpu_to_le16(val);

So existing code is casting already in most of the places this could be
used.  And although this could be made a static inline and get the sparse
checking, we lose one of the big advantages of the open-coding - constants
are byteswapped at compile time.  Although gcc (4.4) grew support for __builtin_constant_p
in static inlines, older gcc's don't, so we would lose that with essentially
all current compilers.

So the option was to make it a static inline and get the sparse checking, or
add the cast in the macro and lose sparse checking but preserve the compile-time
swapping...maybe I chose poorly.

Thoughts?

Harvey


  reply	other threads:[~2009-03-03  0:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03  0:06 [PATCH 1/2] byteorder: add load/store_{endian} API Harvey Harrison
2009-03-03  0:15 ` Linus Torvalds
2009-03-03  0:25   ` Harvey Harrison [this message]
2009-03-03  0:37     ` Linus Torvalds
2009-03-03  0:40       ` Harvey Harrison
2009-03-03  1:51         ` Linus Torvalds
2009-03-03  2:09           ` Harvey Harrison

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=1236039944.5756.19.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bharrosh@panasas.com \
    --cc=geert@linux-m68k.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.