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
next prev parent 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 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.