From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH XEN v2 08/15] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab. Date: Tue, 22 Sep 2015 12:36:46 +0100 Message-ID: <56013D4E.5060509@citrix.com> References: <1436975173.32371.121.camel@citrix.com> <1436975223-11098-8-git-send-email-ian.campbell@citrix.com> <1442921112.10338.153.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1442921112.10338.153.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org Cc: stefano.stabellini@eu.citrix.com, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 22/09/15 12:25, Ian Campbell wrote: > Any thoughts/preferences on this library interface regarding: > > The use of a (perhaps to be added) grant_ref_t in preference to uint32_t as > it is now? Probably a good idea. We should also introduce/use domid_t consistently through the new API as well. > > The use of bool rather than int for "writeable"? Depends if we go for -std=c89 or -std=c99. Given that it is 2015, I vote for -std=c99 and all the niceties it brings, such as bool. > > Mapping functions returning NULL on failure (rather than e.g MAP_FAILED)? > (current code squashes any underlying MAP_FAILED into NULL, but of course > that prevents mapping things at NULL, but then I'm not sure why we would > want to support that). +1 Anyone code choosing to try and map a grant ref at 0 can handcode the systemcalls itself. Sane software will be much happier with NULL as the failure check. ~Andrew