[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/public: arch-arm: Restrict the visibility of struct vcpu_guest_core_regs
>>> On 21.05.19 at 11:35, <julien.grall@xxxxxxx> wrote: > On 5/21/19 10:26 AM, Jan Beulich wrote: >>>>> On 20.05.19 at 20:12, <julien.grall@xxxxxxx> wrote: >>> As this is now Xen and tools only, I am wondering whether the check on >>> GNU_C is still necessary. I am happy to send a follow-up patch (or fold >>> in this one) if it can be removed. >> >> I think this should be dropped if it can be without breaking any >> part of the build. > This is because all the tools are part of xen.git, right? Right - no-one else is supposed to define __XEN_TOOLS__, or if anyone does, they're on their own. >>> --- a/xen/include/public/arch-arm.h >>> +++ b/xen/include/public/arch-arm.h >>> @@ -197,6 +197,7 @@ >>> } while ( 0 ) >>> #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val) >>> >>> +#if defined(__XEN__) || defined(__XEN_TOOLS__) >>> #if defined(__GNUC__) && !defined(__STRICT_ANSI__) >>> /* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */ >>> # define __DECL_REG(n64, n32) union { \ >>> @@ -272,6 +273,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t); >>> >>> #undef __DECL_REG >>> >>> +#endif >> >> If I was the maintainer of this code, I'd ask for the struct declaration >> to be moved (into the existing #if) rather than adding a 2nd #if. > > s/2nd/3rd/ ;) > > The reason I haven't done that is git will generate a completely > unrelated diff. So it makes quite difficult to understand the purpose of > the patch. Well, as said - you're the maintainer. I wouldn't be bothered overly much by a strange diff that might result. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |