Re: [Xen-devel] [PATCH 1/5] xen: improve changes to xen_add_to_physmap

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 8 Aug 2012, Jean Guyader wrote:
> On 8 August 2012 10:51, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Wed, 8 Aug 2012, Jan Beulich wrote:
> >> >>> On 08.08.12 at 09:45, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> > On Wed, 2012-08-08 at 08:14 +0100, Jan Beulich wrote:
> >> >> >>> On 07.08.12 at 19:07, Stefano Stabellini 
> >> >> >>> <stefano.stabellini@xxxxxxxxxxxxx>
> >> > wrote:
> >> >> > Regarding the name, maybe it should be XEN_ADD_TO_PHYSMAP_FIELD?
> >> >>
> >> >> Sounds fine (and I like this better than the ..._ARG one you used
> >> >> below.
> >> >>
> >> >> > #if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || 
> >> >> > (__STDC_VERSION__ >=
> >> > 201112L)
> >> >>
> >> >> #if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || \
> >> >>     (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L)
> >> >
> >> > The downside of this is that users of this header might need to change
> >> > their code depending on what compiler they actually build with today (or
> >> > even what options).
> >> >
> >> > Is adding the ".u" throughout the Xen code base too intrusive?
> >>
> >> I don't know and didn't check; I think the goal was to avoid having
> >> to change consumers that use gcc for compilation.
> >
> > For ARM is not an issue, but the size parameter can be used by out of
> > tree code (V4V?).
> > That's why I CC'ed Jean, I was hoping he was going to say that it is OK
> > to add ".u".
> 
> I have introduced the size field for XENMAPSPACE_gmfn_range and that is used
> by hvmload when we want to relocated the memory because the pci hole needs to 
> be
> bigger.
> 
> Maybe something else use it by now, if not you could get away by just
> updating the Xen
> code to use .u.

Great, I'll do that then.

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