Jan Kiszka wrote:
Unfortunate. But on the one hand, nothing technically prevents defining the IOCTL base on existing kvm_pit_state, but passing down extended kvm_pit_state2 if that negotiation took place. On the other hand, we are not yet running out of IOCTL numbers...
Right, and we are not in any competition for most obfuscated interface yet (though we'd probably get an honourable mention if we were to apply).
However, I guess kvm_pit_state2 will also need some flags field and a bit tail room for potential future extensions.
Yes, it's a common pattern in kvm. -- 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
