public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"H. Peter Anvin" <hpa@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Jaswinder Singh Rajput <jaswinder@kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Jaswinder Singh Rajput <jaswinderrajput@gmail.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] x86: do not expose CONFIG_BSWAP to userspace
Date: Wed, 28 Jan 2009 14:38:34 -0800	[thread overview]
Message-ID: <1233182314.6717.66.camel@brick> (raw)
In-Reply-To: <4980D913.3000505@zytor.com>

On Wed, 2009-01-28 at 14:15 -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > I'm afraid my knowledge of gcc compiler flags for various models is
> > lacking, I used i486 as suggested, just wanted to make sure I understood
> > you corectly.
> 
> You did, but I misremembered... instead of having the __i386__, 
> __i486__, __i586__, __i686__ being an additive chain as would make 
> sense, gcc just has __i386__ plus whichever corresponds to the -march= 
> option.  I keep forgetting this because it's just so incredibly dumb.
> 
> Bloody hell.  This really f*cks thing up.

> What's worse, they seem to simply be adding new options, so at this 
> point you'd actually need something like:
> 
> # if defined(__i486__) || defined(__i586__) || defined(__i686__) || \
> 	defined(__core2__) || defined(__k8__) || defined(__amdfam10__)
> 
> Worse, there isn't any kind of macro that can be used to compare for a 
> negative (i.e. not i386).

Well, that's unfortunate, how about we just export the BSWAP version
unconditionally and hope pure i386 just goes away someday?

> 
> This obviously is screaming to be abstracted away into a header of its 
> own, but it really can't be done cleanly as far as I can tell because of 
> this particular piece of major gcc braindamage.
> 
> So, one ends up doing something like:
> 
> #ifdef __i486__
> # define __CPU_HAVE_BSWAP
> #endif
> #ifdef __i586__
> # define __CPU_HAVE_BSWAP
> #endif
> 
> ... and so on, and have to keep this up to date with the latest 
> inventions of the gcc people.  *Sob.*

Unpleasant indeed.  Is there a byteswap builtin in gcc?  At least AVR32
seems to use it, but perhaps it's not generally exposed...perhaps we
could ask the gcc-folk?

Harvey


  reply	other threads:[~2009-01-28 22:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090127222825.GA27097@elte.hu>
2009-01-27 22:57 ` [mingo@elte.hu: [git pull] headers_check fixes] Linus Torvalds
2009-01-27 23:22   ` H. Peter Anvin
2009-01-27 23:29     ` Linus Torvalds
2009-01-28  0:12       ` H. Peter Anvin
2009-01-28  0:19         ` Linus Torvalds
2009-01-28  1:02           ` H. Peter Anvin
2009-01-27 23:31   ` Ingo Molnar
2009-01-27 23:43     ` Linus Torvalds
2009-01-27 23:51     ` Vegard Nossum
2009-01-30 14:01     ` Jaswinder Singh Rajput
2009-01-30 18:20       ` Ingo Molnar
2009-01-28  0:03   ` Harvey Harrison
2009-01-28  1:36   ` Jaswinder Singh Rajput
2009-01-28 12:37     ` Arnd Bergmann
2009-01-28 17:48       ` H. Peter Anvin
2009-01-28 19:22         ` Harvey Harrison
2009-01-28 19:44           ` Linus Torvalds
2009-01-28 20:03             ` Harvey Harrison
2009-01-28 21:25               ` H. Peter Anvin
2009-01-28 21:58                 ` [PATCH] x86: do not expose CONFIG_BSWAP to userspace Harvey Harrison
2009-01-28 22:13                   ` Linus Torvalds
2009-01-28 22:40                     ` Harvey Harrison
2009-01-30 20:37                       ` Pavel Machek
2009-01-28 22:15                   ` H. Peter Anvin
2009-01-28 22:38                     ` Harvey Harrison [this message]
2009-01-28 23:04                       ` Ben Pfaff
2009-01-30 18:20                         ` H. Peter Anvin
2009-01-28 23:27                       ` H. Peter Anvin
2009-01-28 23:36                         ` Harvey Harrison
2009-01-28 23:47                           ` H. Peter Anvin
2009-02-03 18:19                             ` Arnd Bergmann
2009-01-31 18:43                       ` Maciej W. Rozycki
2009-01-31 20:24                         ` H. Peter Anvin
2009-01-28 23:24                     ` Arnd Bergmann
2009-01-28 23:30                       ` H. Peter Anvin
2009-01-28 20:49             ` [mingo@elte.hu: [git pull] headers_check fixes] Sam Ravnborg
2009-01-28 21:23           ` H. Peter Anvin
2009-01-28 21:06   ` Sam Ravnborg

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=1233182314.6717.66.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=hpa@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jaswinder@kernel.org \
    --cc=jaswinderrajput@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox