>>> Razvan Cojocaru <rcojocaru@bitdefender.com> 04/14/16 11:37 AM >>>
>On 04/13/2016 06:05 PM, Tamas K Lengyel wrote:
>>
>> Yea, well then we need to introduce a new struct with a new subop to
>> pass the bitmask. I guess its a lesson in ABI design to leave some
>> wiggle room for future-proofing it (my bad). So I guess we can introduce
>> XEN_DOMCTL_MONITOR_OP_ENABLE_V2 and struct xen_domctl_monitor_op_v2
>> where say expand the union to uint64_t just in case?
>
>I can do that, but it would seem that this is somewhat at odds with
>Andrew Cooper's perspective - he has stated that it's within the rules
>and the domctl can be changed without there being the need for
>XEN_DOMCTL_MONITOR_OP_ENABLE_V2. So this should be clarified, please,
>otherwise I'm incurring the risk of changing the code only to have to
>revert it later.

You basically have two options - the new sub-op or changing the existing
one while (if not already done so in a dev cycle) bumping the domctl
interface version.