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? > >> 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? We only have to make sure we don't actually release the intermediate steps as an upstream kernel then, right? 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
