On 09/04/15 12:15, Tamas Lengyel wrote:


On Thu, Apr 9, 2015 at 1:07 PM, Tamas Lengyel <tamas.lengyel@zentific.com> wrote:


On Thu, Apr 9, 2015 at 1:03 PM, Tim Deegan <tim@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