On 11/01/2011 06:16 PM, Scott Wood wrote: > > > > sizeof(struct kvm_tlb_dirty) == 12 for 32-bit userspace, but == 16 for > > 64-bit userspace and the kernel. ABI structures must have the same > > alignment and size for 32/64 bit userspace, or they need compat handling. > > The size is 16 on 32-bit ppc -- the alignment of __u64 forces this. It > looks like this is different in the 32x86 ABI.
Right, __u64 alignment on i386 is 4. > We can pad explicitly if you prefer. No real need - unless it may be reused by another arch? I think that's unlikely. > >> This API has been discussed extensively, and the code using it is > >> already in mainline QEMU. This aspect of it hasn't changed since the > >> discussion back in February: > >> > >> http://www.spinics.net/lists/kvm/msg50102.html > >> > >> I'd prefer to avoid another round of major overhaul without a really > >> good reason. > > > > Me too, but I also prefer not to make ABI choices by inertia. ABI is > > practically the only thing I care about wrt non-x86 (other than > > whitespace, of course). Please involve me in the discussions earlier in > > the future. > > You participated in that thread. :-) Well, my memory isn't what it used to be, or at least what I seem to remember it used to be. > >> > >> These are the assumptions needed to make such an interface well-defined. > > > > Just remarking on the complexity, don't take it personally. > > :-) > > Just wasn't sure whether the implication was that it was too complex. > It is too complex, but that's entirely the fault of the hardware. All we can do is complain and enjoy the guaranteed job security. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
