On Wed, 4 Feb 2015, Dave Jones wrote:
> On Tue, Feb 03, 2015 at 12:01:23PM -0500, Vince Weaver wrote:
>
>
> > @@ -237,6 +238,7 @@ enum perf_event_read_format {
> > #define PERF_ATTR_SIZE_VER2 80 /* add: branch_sample_type */
> > #define PERF_ATTR_SIZE_VER3 96 /* add: sample_regs_user */
> > /* add: sample_stack_user */
> > +#define PERF_ATTR_SIZE_VER4 104 /* add: sample_regs_intr */
>
> I've not given this a lot of thought before, but I'm assuming these
> are the 64-bit struct sizes. It might be interesting to also
> throw some 32-bit sizes in the mix. Who knows what horrors
> lie in wait for the compat syscalls.
I might be misunderstanding, but I think the attr structure is defined in
a way that it has the same size on 32 and 64 bit.
Now, there are bitfields mixed into the interface so it causes some
unspeakable horrors if you try to do cross-endian stuff (as some powerpc
people have discovered), but I think as far as structure size goes the
interface is clear.
I do have to admit though that at least the perf_fuzzer only does native
calls to the system calls so I never stress the compat code at all.
Vince
--
To unsubscribe from this list: send the line "unsubscribe trinity" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
