On 30.06.2011, at 18:00, Avi Kivity <[email protected]> wrote: > On 06/30/2011 06:22 PM, Alexander Graf wrote: >>> Regarding that. There's another option - the ioctl code embeds the >>> structure size. So if we extend the ioctl parsing to pad up (or truncate >>> down) from the user's size to our size, and similarly in the other >>> direction, we can get away from this ugliness. >>> >>> Some years ago I posted a generic helper that did this (and also kmalloc'ed >>> and kfree'd the data itself), but it wasn't received favourably. Maybe I >>> should try again (and we can possibly use it in kvm even if it is rejected >>> for general use, though that's against our principles of pushing all >>> generic infrastructure to the wider kernel). >> >> >> That does sound interesting, but requires a lot more thought to be put into >> the actual code, as we basically need to read out the feature bitmap, then >> provide a minimum size for the chosen features and then decide if they fit >> in. > > > Why? just put the things you want in the structure. > > old userspace -> new kernel: we auto-zero the parts userspace left out, and > zero means old behaviour, so everthing works > new userspace -> old kernel: truncate. Userspace shouldn't have used any new > features (KVM_CAP), and we can -EINVAL if the truncated section contains a > nonzero bit.
Yup, which requires knowledge in the code on what actually fits :). Logic we don't have today. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
