Re: [patch 05/24] perfmon: X86 generic code (x86)

From: Thomas Gleixner
Date: Wed Nov 26 2008 - 11:39:52 EST


Stephane,

On Wed, 26 Nov 2008, stephane eranian wrote:
> > I have not yet found a good reason why it needs to use u64 instead of
> > using what's there already.
> >
> There is a good reason why we cannot use unsigned long. We must make sure
> all data structures exchanged between user mode and the kernel have fixed size.
> This way, we can have a 32-bit tool run unmodified on top of a 64-bit kernel AND
> we do not need trampoline code to marshall/unmarshall the parameters.

That's not a good reason at all. We have in kernel interfaces and
kernel-userspace interfaces. Making them the same is nice if it works,
but horrible if it imposes crappy hackery like the bitops wrappers.

> And yes, the abstraction for bitmask ops was introduced because of issues
> casting u64 -> unsigned long on Big-Endian32-bit machines such as PPC32.

Sorry, I think it is simply stupid.

You can keep the userspace interface u64 and use unsigned long for the
bitmasks in the kernel and take care of it in the user space interface
code and do the BE32 conversion when you copy stuff from and to user.

That's a single well defined place and does not add extra crappola
over the kernel especially not into hot pathes like the interrupt.

Why do you want to do u64 -> u32 BE32 magic on every interrupt,
context switch etc., if you can do it once in the userspace interface ?

Thanks,

tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/