On 06/30/2011 07:33 PM, Alexander Graf wrote:
On 30.06.2011, at 18:00, Avi Kivity<a...@redhat.com> 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.
I don't follow. What knowledge is required? Please give an example.
--
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
