>>> Razvan Cojocaru <rcojoc...@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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
