On 09/04/2012 04:59 PM, Alexander Graf wrote: >> >> Not is you pack the pointer in a __u64, which is what we do to preserve >> padding. Then it is only s390 which needs extra love. > > I doubt that anyone wants to run 31-bit user space on an s390x system. In > fact, I wouldn't be surprised if exactly that case is broken already.
Arnd sent patches to fix it long ago. Of course, something else may be broken. > >> >>>>> I don't think that is what makes the API hard >>>>> to use. >>>> >>>> What is it then? I forgot what the original complaints/complainers were. >>> >>> I have no idea, since I didn't hear the complaints. But any non-fixed >>> size array has issues in C; there's not much we can do about it. >>> >>> x86 manages this fine for msrs, and I didn't have a problem using it for >>> my test programs. That's the limit of my experience, however. >> >> Another option is to use the size parameter from the ioctl. It just >> sits there doing nothing. > > It would require quite a bunch of changes throughout the stack. Even in user > space, like strace... I'm sure strace could cope. I once had a proposal for extensible ioctl using the size parameter. You want to extend an ioctl, the kernel zero-extends the input struct for you, and truncates it on the way back. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
