[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1211321725.5915.208.camel@brick>
Date: Tue, 20 May 2008 15:15:25 -0700
From: Harvey Harrison <harvey.harrison@...il.com>
To: David Miller <davem@...emloft.net>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] byteorder: eliminate pointer bytorder api
On Tue, 2008-05-20 at 14:17 -0700, David Miller wrote:
> From: Harvey Harrison <harvey.harrison@...il.com>
> Date: Tue, 20 May 2008 12:24:09 -0700
>
> > Not a great api, should be using cpu_to_etc and deref the pointer yourself.
> > cpu_to_le16p
> > cpu_to_le32p
> > cpu_to_le64p
> > cpu_to_be16p
> > cpu_to_be32p
> > cpu_to_be64p
> >
> > Replaced by the aligned get_/put_ helpers
> > le16_to_cpup
> > le32_to_cpup
> > le64_to_cpup
> > be16_to_cpup
> > be32_to_cpup
> > be64_to_cpup
> >
> > Also add const to the get/put helpers and use them in the access_ok case for
> > unaligned access.
> >
> > Signed-off-by: Harvey Harrison <harvey.harrison@...il.com>
>
> But what you're doing in the first patch is killing performance for some
> cases.
>
> The reason we use the cpu_to_*p() interfaces is to get the other-endian
> load and store instructions some processors have.
>
> What you're doing is undoing all of that work we've done to take
> advantage of such things.
Obviously I missed that part, my apologies. Would it be acceptable if,
taking the possibly arch-specific parts, moved the [endian]_to_cpup
name over to get_[endian]
ie:
le16_to_cpup -> get_le16
I'd leave cpu_to_le16p alone (it's not used that much anyway).
To make it similar to the get_unaligned_le16 helpers?
Thanks for having a look,
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists