From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH XEN v2 08/15] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab. Date: Tue, 22 Sep 2015 13:51:19 +0100 Message-ID: <1442926279.10338.162.camel@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> <56013D4E.5060509@citrix.com> <22017.19563.847324.14337@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22017.19563.847324.14337@mariner.uk.xensource.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 Jackson , Andrew Cooper Cc: roger.pau@citrix.com, wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, 2015-09-22 at 13:41 +0100, Ian Jackson wrote: > Andrew Cooper writes ("Re: [Xen-devel] [PATCH XEN v2 08/15] tools: > Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab."): > > 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? > > Is a grant_ref_t uint32_t ? Yes (in xen/include/public/grant_table.h). > > Probably a good idea. We should also introduce/use domid_t > > consistently > > through the new API as well. > > domid_it is a uint16_t. The problem with that is that there is no > space for sentinel or magic values which are assigned meanings outside > the hypervisor. Correct. We don't necessarily need to use the same domid_t as the hypervisor interface, but not doing so would seem confusing... > > Given that it is 2015, I vote for -std=c99 and all the niceties it > > brings, such as bool. > > We should certainly consider some GNU extensions. I don't know which > are widely available, but we should consider: > * Statement expressions > * Some of the function and data attributes, particularly > format, noreturn, unused. (Maybe via some compatibility macros.) > * Anonymous struct/union members. > * typeof For the implementation side, sure, few of these seem relevant to the interface headers being discussed here (apart maybe from anon members, which is moot because none of the libraries in question have a need for such a thing AFAICT). Ian.