Re: [Xen-devel] [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping into libxenforeignmemory

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: 30 November 2015 09:52
> To: Paul Durrant; Andrew Cooper; Ian Jackson
> Cc: Wei Liu; xen-devel@xxxxxxxxxxxxx; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping
> into libxenforeignmemory
> 
> On Sun, 2015-11-29 at 09:54 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > [snip]
> > > > C99 was 16 years ago now, I'm struggling to think of a reason not to
> > > > move
> > > > the baseline for tools stuff at least to that.
> > > >
> > > > https://en.wikipedia.org/wiki/Visual_C%2B%2B might be one such
> reason
> > > > I
> > > > suppose, although I'm not convinced a libvchan port to Windows, even
> > > > if
> > > not
> > > > entirely hypothetical, would be using any of xen.git/tools/libs/*
> > > > rather
> > > > than the equivalent frameworks provided by the Windows PV drivers.
> > >
> > > It would be nice to at least be able to use the same header files, for
> > > ease of porting userspace software.
> > >
> >
> > It's possible that libvchan on Windows will make use of the tools/libs
> > headers. As Andy says it would ease porting client software.
> >
> > > In this case, VLAs are just being used as an aid for the compiler to
> > > spot errors.ÂÂIt doesn't change the API/ABI, and could be #ifdef'd
> > > around, if we care both for using C99 in general, and Windows support.
> > >
> >
> > We still compile with VS2012 in Citrix and Xen Project uses VS2013 so we
> > can't rely on C99. A #ifdef here does seem like the best solution.
> 
> Would you expect new projects (i.e. stuff based on tools/libs) to continue
> to have requirements to build with those older versions? (Although with
> Andy's link saying even VS2015 doesn't do VLAs maybe it is a bit moot).
> 

It would certainly be preferable to have something that did build under a 
sufficiently old C standard to cover as many environments as is reasonable, and 
I think any supported MSVC build environment should be included in that set 
(although I have no problem using #ifdefs to achieve that).

> I don't think using VLA here is worth an ifdef, but I think it is worth
> reordering the arguments such that once we end up with a new enough
> compiler baseline (in $donkeys years) we can switch without changing the
> ABI (I think that's the case).
> 

IIUC correctly the use of VLAs does not change the calling convention in any 
way, right? It would still mean a pointer to err_out is passed and the use of a 
VLA is so that bounds checking can be performed?
I certainly don't think we should get ourselves into a situation where 
additions to compilers or C standards do cause changes in the ABI (and we 
already have to be careful with Windows 32-bit since it defaults to pascal 
calling convention).

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel