* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Mar 5, 2016 at 8:52 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > On Sat, Mar 05, 2016 at 02:50:06PM +0100, Ingo Molnar wrote:
> >> A more workable method would be to have a test .c file that includes all UAPI
> >> structures in existence and defines a variable out of every single one, and then
> >> generates a list of sizeof() values or so. But even that isn't perfect: a
> >> structure might shift some fields forward, into a pre-existing hole, without
> >> changing the sizeof? We'd need a list of all field offsets in all structures to be
> >> really sure, and that's nasty.
> >
> > pahole has such logic, right?
>
> sparse could be taught to warn about unaligned u64's, but there are
> still config issues and issues across other architectures, and if some
> case gets missed it can be really quite painful.
So I think what might work is to define bitness and alignment-independent ABI
structures, and add (tooling) infrastructure to enforce that invariance.
For example every ABI detail in include/uapi/linux/perf_event.h is supposed to be
alignment-independent: it should be the same structure and same fields on all
32-bit and 64-bit platforms, regardless of the natural alignment of u64.
It's as close to an 'architecture independent' ABI as we can get IMHO. (With the
notable exception of endianness: making endianness an invariant via dynamic
endianness flags or so would be a mistake IMHO - structures that can be
transmitted between different machines via network or via disk should pick one
particular endianness statically and stick with that.)
If we can build tooling that checks _that_ kind of struct/ABI invariance, it would
be a lot easier to ensure that future changes don't break the ABI.
New structures could be annotated to be arch-invariant, via something like:
struct foo __arch_invariant_ABI {
...
};
and tooling could pick it up from there.
We do have a healthy body of 'messy' ABIs, which make liberal use of longs,
unaligned u64's and other non-invariant constructs - those would have to be
cleaned up and in the worst case they would have to be split into several explicit
variants.
I tried to do something like that with a particularly messy x86 header lately, see
arch/x86/include/uapi/asm/sigcontext.h, but it's a pretty slow and painful process
altogether...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|