On 03/08/2010 04:10 PM, Alexander Graf wrote:
When we have reserved fields which are later used for something new, the kernel needs a way to know if the reserved fields are known or not by userspace. One way to do this is to assume a value of zero means the field is unknown to usespace so ignore it. Another is to require userspace to set a bit in an already-known flags field, and only act on the new field if its bit was set. This has the advantage that the old kernel checks for unknown flags and errors out, improving forwards and backwards compatibility. I thought ->cap was already a bit field, so this isn't necessary, but if it isn't, then a flags field is helpful.-> cap is the capability number. So you want something like: struct kvm_enable_cap { __u32 cap; __u32 flags; __u64 args[4]; __u8 pad[64]; }; And then check for flags == 0 in the ioctl handler? Flags could later on define if the padding changed to a different position, adding new fields in between args and pad?
Exactly, we do so in several places. Can be useful if, for example, some new capability comes with a resource count value.
What's this thing anyway? like cpuid bits for x86? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
