From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH V8 00/12] xen: Clean-up of mem_event subsystem Date: Thu, 9 Apr 2015 12:21:18 +0100 Message-ID: <552660AE.30400@citrix.com> References: <1427404024-30567-1-git-send-email-tamas.lengyel@zentific.com> <20150409110318.GB17025@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1949628409246272183==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1949628409246272183== Content-Type: multipart/alternative; boundary="------------080909090602090407030700" --------------080909090602090407030700 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit On 09/04/15 12:15, Tamas Lengyel wrote: > > > On Thu, Apr 9, 2015 at 1:07 PM, Tamas Lengyel > > wrote: > > > > On Thu, Apr 9, 2015 at 1:03 PM, Tim Deegan > 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 --------------080909090602090407030700 Content-Type: text/html; charset="windows-1252" Content-Length: 5077 Content-Transfer-Encoding: quoted-printable
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):
>=A0 =A0xen/mem_event: Cleanup of mem_event structures
>=A0 =A0xen/mem_event: Cleanup mem_event names in rings, functions and domctls
>=A0 =A0xen/mem_paging: Convert mem_event_op to mem_paging_op and cleanup
>=A0 =A0xen: Rename mem_event to vm_event
>=A0 =A0tools/tests: Clean-up tools/tests/xen-access
>=A0 =A0x86/hvm: factor out and rename vm_event related functions

I have applied these six patches.

>=A0 =A0xen: 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=3F
Absolutely. Will be sending it shortly, thanks.

Tamas
=A0

Cheers,

Tim.

What's the policy on reusing DOMCTL numbers=3F I see XEN_DOMCTL_arm_configure_domain has been retired in the conflicting patch. Should I just reuse it's number for monitor_op=3F 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.=A0 We have 32bits worth of domctl subop space - we can afford to have a few holes ;)

~Andrew
--------------080909090602090407030700-- --===============1949628409246272183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1949628409246272183==--