From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH 6/18 V2]: PVH xen: Introduce PVH guest type
Date: Mon, 25 Mar 2013 12:05:07 -0700
Message-ID: <20130325120507.5621a913@mantra.us.oracle.com>
References: <20130315173240.591f9784@mantra.us.oracle.com>
	<51470E8502000078000C652A@nat28.tlf.novell.com>
	<20130318172122.05a084e3@mantra.us.oracle.com>
	<5148348502000078000C6A17@nat28.tlf.novell.com>
	<20130322181326.20735778@mantra.us.oracle.com>
	<5150266B02000078000C802D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5150266B02000078000C802D@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, 25 Mar 2013 09:26:51 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 23.03.13 at 02:13, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Tue, 19 Mar 2013 08:48:53 +0000
> > "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> > suggest we leave it as is. is_hvm_or_pvh_domain is nicely
> >> > readable, what name do you suggest?
> >> 
> >> No. The three kinds should be fully distinct, such that when
> >> meaning one you can use is_xyz_domain() and when meaning
> >> two, you can use !is_abc_domain().
> > 
> >> is_hvm_or_pvh_domain() isn't nicely readable to me, in particular
> >> because this kind of naming doesn't scale. And it's certainly more
> >> typing than !is_pv_domain().
> > 
> > Since, pvh is a pv domain, I don't like using pv_guest for non PVH
> > PV. But perhaps I could use the name pv_mmu and have something like
> > following:
> > 
> > enum guest_type { is_mmu_pv, is_pvh_pv, is_hvm } guest_type;
> > 
> > Then:  is_hvm_or_pvh_domain()  becomes:  !is_mmu_pv().
> > 
> > Alternative to is_mmu_pv: is_pure_pv, is_orig_pv, ....
> 
> These are all ugly, and I don't see why the triplet I suggested
> (is_pv, is_pvh, and is_hvm), including their intended use, wouldn't
> be acceptable.

Because this implies pvh is a new type, whereas like I said before,
PVH is a PV guest. Ok, lets go with your suggestion above, and if
people find it confusing, we can change in future.

Thanks,
Mukesh