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.
--
error compiling committee.c: too many arguments to function
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
