On Fri, Sep 30, 2016 at 03:05:18AM -0600, Jan Beulich wrote: > >>> On 29.09.16 at 21:22, <julien.gr...@arm.com> wrote: > > > > > On 29/09/2016 12:11, Julien Grall wrote: > >> Hi Jan, > >> > >> On 28/09/2016 23:04, Jan Beulich wrote: > >>>>>> On 28.09.16 at 21:42, <julien.gr...@arm.com> wrote: > >>>> Hi Jan, > >>>> > >>>> On 28/09/2016 05:00, Jan Beulich wrote: > >>>>> For consumers not using (fully) C99-aware compilers, limit the number > >>>>> of places where tweaking of the headers would be necessary: Introduce > >>>>> and use xen_mk_ullong(), allowing its helper macro to be overridden at > >>>>> once. > >>>>> > >>>>> For now don't touch public/io/, which also has a few offenders. > >>>>> > >>>>> The need to include xen.h in hvm/e820.h demonstrates that it is a bad > >>>>> idea to include public headers first thing - arch/x86/hvm/mtrr.c needs > >>>>> adjustment just because of this. > >>>>> > >>>>> Signed-off-by: Jan Beulich <jbeul...@suse.com> > >>>>> --- > >>>>> I wonder why all those ARM constants carry the ULL suffix despite only > >>>>> two of them actually exceeding 32 significant bits. > >>>> > >>>> I am not the author of the code, but I think it was to declare all the > >>>> constants of a given set uniformed. > >>>> > >>>> For instance all the GUEST_* constants are used to define the layout of > >>>> the guest. This may be shuffle in this future (this is not part of ABI) > >>> > >>> Oh, they're in a Xen/tools only section (the #endif could really be > >>> annotated to help spot this) - in that case I could as well leave them > >>> alone. Any preference? > >> > >> Correct. I can send a patch to annotate the #endif. > > > > It looks like that I did not reply to your question. Do we expect the > > toolstack to always C99 standard? If not, then we should keep the > > xen_mk_ullong. > > We're even expecting GNUisms to be supported, like > __attribute__((aligned(...))). But since you said you're fine either > way, I guess I'll keep the patch as is. >
Acked-by: Wei Liu <wei.l...@citrix.com> I will commit this patch soon. Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel