public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "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: [mingo@elte.hu: [git pull] headers_check fixes]
Date: Wed, 28 Jan 2009 12:03:14 -0800	[thread overview]
Message-ID: <1233172994.6717.56.camel@brick> (raw)
In-Reply-To: <alpine.LFD.2.00.0901281141510.3123@localhost.localdomain>

On Wed, 2009-01-28 at 11:44 -0800, Linus Torvalds wrote:
> 
> On Wed, 28 Jan 2009, Harvey Harrison wrote:
> > On Wed, 2009-01-28 at 09:48 -0800, H. Peter Anvin wrote:
> > > 
> > > In general, no.  The byteswap API is a legacy exception.
> > 
> > But now that swab.h has been separated out, we could just stop exporting the
> > asm/swab.h bits while still providing a generic C-based implementation to
> > userspace.
> 
> Well, the _reason_ the byteswap stuff has been interesting to user space 
> is that the kernel did it better than the alternatives. Rather than having 
> purely "work with big-endian data" (the networking htonl etc functions), 
> the kernel had good and fairly optimized handling of various different 
> forms of byte order handling.
> 
> Which is why people wanted to use it in the first place - and which is why 
> then doing just the generic C-based thing doesn't really fix the issue. 
> Things may compile, but they kind of lost the point.

There was at least some discussion on the gcc-list in November about recognizing
the byteswap idiom and inserting optimized instructions if available...so hopefully
in the future this just fixes itself.

For now, the problem is with arches like X86 that need to test the availability of
an instruction.  So the arch versions could be unconditionally offered on X86_64
and the lowest-common denominator (no BSWAP) on X86-32.  If we still want the
optimized (BSWAP) versions on X86-32 the tests will have to use the compiler arch flags
as opposed to CONFIG_BSWAP....which is probably not worth the trouble.

Harvey


  reply	other threads:[~2009-01-28 20:03 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 [this message]
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
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=1233172994.6717.56.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=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