On 09/04/15 12:15, Tamas Lengyel wrote: > > > On Thu, Apr 9, 2015 at 1:07 PM, Tamas Lengyel > <tamas.leng...@zentific.com <mailto:tamas.leng...@zentific.com>> wrote: > > > > On Thu, Apr 9, 2015 at 1:03 PM, Tim Deegan <t...@xen.org > <mailto:t...@xen.org>> wrote: > > Hi, > > Sorry for the delay - I have been away. > > At 22:06 +0100 on 26 Mar (1427407612), Tamas K Lengyel wrote: > > Tamas K Lengyel (12): > > xen/mem_event: Cleanup of mem_event structures > > xen/mem_event: Cleanup mem_event names in rings, functions > and domctls > > xen/mem_paging: Convert mem_event_op to mem_paging_op and > cleanup > > xen: Rename mem_event to vm_event > > tools/tests: Clean-up tools/tests/xen-access > > x86/hvm: factor out and rename vm_event related functions > > I have applied these six patches. > > > xen: Introduce monitor_op domctl > > This one no longer applies cleanly - looks like a conflict > with a7511905 > ("xen: Extend DOMCTL createdomain to support arch configuration") > > Can you rebase the second half of the series please? > > > Absolutely. Will be sending it shortly, thanks. > > Tamas > > > > Cheers, > > Tim. > > > What's the policy on reusing DOMCTL numbers? I see > XEN_DOMCTL_arm_configure_domain has been retired in the conflicting > patch. Should I just reuse it's number for monitor_op? For the most > part domctl numbers seem to be continuous but there are holes (30-32) > so I'm not sure.
While technically speaking it would be fine to reuse, given the INTERFACE_VERSION, it would be better to leave the holes as -ENOSYS to positively catch potential issues. We have 32bits worth of domctl subop space - we can afford to have a few holes ;) ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
