From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH XEN v5 07/23] tools: Refactor
 /dev/xen/gnt{dev, shr} wrappers into libxengnttab.
Date: Wed, 25 Nov 2015 15:06:31 +0000
Message-ID: <1448463991.17688.118.camel@citrix.com>
References: <1447070397.27774.11.camel@citrix.com>
	<1447070458-31104-1-git-send-email-ian.campbell@citrix.com>
	<1447070458-31104-8-git-send-email-ian.campbell@citrix.com>
	<22083.22696.351853.213216@mariner.uk.xensource.com>
	<1448298339.4973.77.camel@citrix.com>
	<1448357671.13926.39.camel@citrix.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: <1448357671.13926.39.camel@citrix.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: Ian Jackson <Ian.Jackson@eu.citrix.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Tue, 2015-11-24 at 09:34 +0000, Ian Campbell wrote:
> Thinking about this some more overnight, it occurred to me that the
> real issue is that gnttab and gntshr are actually two quite difference
> APIs. gnttab is all about consuming grant references which are given to
> you from elsewhere while gntshr is all about creating grant references
> to give to others. They have relatively little in common wrt the
> underlying infrastructure, e.g. gnttab is mostly about making GNTTABOP
> hypercalls while gntshr mostly interacts with the kernel's grant ref
> allocator with no interaction with the hypervisor.
> 
> Maybe that and the API issues above constitute an argument for not
> combining, I'm really not sure.

Ian and I discussed this (briefly) in real life and based on the above
argumentation we decided that keeping the two APIs separate (but in the
same library) was justified, since there is a reasonable enough air gap
between their functionality (i.e. consuming vs producing grants).

We did wonder a bit about changing the names to make that divide clearer,
but couldn't think of anything especially compelling and decided to stick
with the current shade of yellow.

Ian.