On 04.07.2011, at 13:22, Avi Kivity wrote: > On 07/04/2011 01:59 PM, Alexander Graf wrote: >> On 03.07.2011, at 11:12, Avi Kivity wrote: >> >> > On 07/03/2011 12:09 PM, Alexander Graf wrote: >> >> > >> >> > Right. The idea is that if KVM_FLAG_BLAH implies a field >> >> kvm_struct::blah, then either both are present in the headers, or none >> >> of them. >> >> >> >> Yup, makes sense. I like the idea :). Gets rid of all the useless >> >> paddings and reserved fields. We could even truncate the structs that >> >> already have paddings in them if we only copy min(sizeof(real_struct), >> >> ioctl_passed_size); (which we should anyways). >> >> >> > >> > No, we can't change anything that is already out. If will change the >> > ioctl numbers, so building against new headers but running against an old >> > kernel will fail. >> >> So this will only be enabled for completely new ioctls? > > Yes, unfortunately. > >> > >> >> How long until we get a patch set? :) >> > >> > Well, I'd really like to get the qemu memory API out first. >> >> Can we add the ioctl without padding now then and add your awesome >> extensibility stuff to it later on? > > Yes. > >> We only have to make sure we don't actually release the intermediate steps >> as an upstream kernel then, right? > > What intermediate steps? We can't add fields to the structure before we get > the extensibility infrastructure, but that's all.
If we add it now without extensibility code, we will have a kernel that only knows the ioctl with the size as it is now. If we later add another field, the ioctl size changes which would render new user space running on that particular kernel to fail, because it doesn't have the "just truncate the ioctl param to the size" logic yet. Alex -- 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
