[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131003053944.GD17237@concordia>
Date: Thu, 3 Oct 2013 15:39:44 +1000
From: Michael Ellerman <michael@...erman.id.au>
To: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Michael Ellerman <michaele@....ibm.com>,
linux-kernel@...r.kernel.org,
Stephane Eranian <eranian@...gle.com>, linuxppc-dev@...abs.org,
Paul Mackerras <paulus@...ba.org>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Subject: Re: [PATCH 6/9][v5] powerpc/perf: Define big-endian version of
perf_mem_data_src
On Tue, Oct 01, 2013 at 05:15:07PM -0700, Sukadev Bhattiprolu wrote:
> perf_mem_data_src is an union that is initialized via the ->val field
> and accessed via the bitmap fields. For this to work on big endian
> platforms, we also need a big-endian represenation of perf_mem_data_src.
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index ca1d90b..846f399 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -19,6 +19,50 @@
> #include <asm/byteorder.h>
>
> /*
> + * Kernel and userspace check for endianness in incompatible ways.
> + * In user space, <endian.h> defines both __BIG_ENDIAN and __LITTLE_ENDIAN
> + * but sets __BYTE_ORDER to one or the other. So user space uses checks are:
Why can't you use __BIG_ENDIAN_BITFIELD ?
cheers
--
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