[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130811171535.GA31780@us.ibm.com>
Date: Sun, 11 Aug 2013 10:15:35 -0700
From: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
To: Vince Weaver <vince@...ter.net>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
Stephane Eranian <eranian@...gle.com>,
Paul Mackerras <paulus@...ba.org>,
Anton Blanchard <anton@....ibm.com>,
Michael Ellerman <michael@...erman.id.au>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Subject: Re: [PATCH 5/7] powerpc/perf: Define big-endian version of
perf_mem_data_src
Vince Weaver [vince@...ter.net] wrote:
| On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote:
|
| >
| > include/uapi/linux/perf_event.h | 55 +++++++++++++++++++++++++++++++++++++++
| > 1 files changed, 55 insertions(+), 0 deletions(-)
|
| > +#define __PERF_LE 1234
| > +#define __PERF_BE 4321
| > +
| > +#if defined(__KERNEL__)
|
| I could be wrong, but I thought files under uapi weren't supposed to
| contain __KERNEL__ code. Wasn't that the whole point of uapi?
|
| Also having the perf_event interface depend on endianess just seems like a
| complicated mess. Can't we just declare the interface to be a certain
| endianess and have the kernel byte-swap as necessary?
Except for the __KERNEL__ check, it looked like this approach would keep
the kernel and user code same. Would it complicate user space ?
I tried to avoid the __KERNEL__ check hack, but like I tried to explain
in the patch, user space and kernel do the endian check differently.
And, there are about ~300 sites in the kernel with __*ENDIAN checks
Sukadev
--
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