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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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