Re: [Xen-devel] [PATCH 2/5] xen: only expose start_info on architectures which have a PV boot path

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-07-18 at 15:12 +0100, Jan Beulich wrote:
> >>> On 18.07.13 at 16:08, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Thu, 2013-07-18 at 15:04 +0100, Jan Beulich wrote:
> >> >>> On 18.07.13 at 15:57, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> > On Thu, 2013-07-18 at 14:38 +0100, Jan Beulich wrote:
> >> >> >>> On 18.07.13 at 15:15, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> >> >> > --- a/xen/include/public/arch-x86/xen.h
> >> >> > +++ b/xen/include/public/arch-x86/xen.h
> >> >> > @@ -70,6 +70,9 @@ typedef unsigned long xen_pfn_t;
> >> >> >  #define PRI_xen_pfn "lx"
> >> >> >  #endif
> >> >> >  
> >> >> > +#define XEN_HAVE_PV_GUEST_ENTRY 1
> >> >> > +#define COMPAT_HAVE_PV_GUEST_ENTRY 1
> >> >> 
> >> >> This ought to nevertheless have a XEN_ prefix, if it really is
> >> >> needed at all (didn't spot yet where it's being consumed).
> >> > 
> >> > It gets used in the autogenerated xen/include/compat/xen.h:
> >> >         ifdef COMPAT_HAVE_PV_GUEST_ENTRY
> >> >         struct compat_start_info {
> >> >         ...
> >> > 
> >> > I think the COMPAT prefix is consistent with other aspects of this
> >> > autogeneration (in particular the struct renaming xen_xxx -> compat_xxx)
> >> 
> >> Yeah, except that these auto-generated pieces are part of the
> >> public interface. I don't mind the definitions getting added, what
> >> I do mind is them getting into the public headers.
> > 
> > So where should they go instead?
> 
> Perhaps into asm-x86/config.h, which already has a couple of
> other COMPAT_* ones derived from public XEN_* ones.
> 
> And perhaps the COMPAT_* definition should then also simply
> use the XEN_* one as its expansion, rather than saying "1"
> literally.

Sounds good. I've noticed one other fixlet which I need (to 5/5) so I'll
resend with that change too.

Ian.


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