Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 04.07.2011, at 13:22, Avi Kivity wrote:

On 07/04/2011 01:59 PM, Alexander Graf wrote:

quoted

On 03.07.2011, at 11:12, Avi Kivity wrote:
=20

quoted

 On 07/03/2011 12:09 PM, Alexander Graf wrote:

quoted

 >
 >   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.

quoted

quoted

quoted

 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).

quoted

quoted

quoted

 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.

quoted

=20
So this will only be enabled for completely new ioctls?

=20
Yes, unfortunately.
=20

quoted

quoted

quoted

 How long until we get a patch set? :)

 Well, I'd really like to get the qemu memory API out first.

=20
Can we add the ioctl without padding now then and add your awesome =

extensibility stuff to it later on?

=20
Yes.
=20

quoted

We only have to make sure we don't actually release the intermediate =

steps as an upstream kernel then, right?

=20
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