On 04/14/2016 06:33 PM, Tamas K Lengyel wrote: > > > On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich <jbeul...@suse.com > <mailto:jbeul...@suse.com>> wrote: > > >>> Razvan Cojocaru <rcojoc...@bitdefender.com > <mailto: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. > > > If bumping the domctl version is not too much hassle I think that would > be the easiest.
Fair enough, I'll look into that option then. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
