[Xen-devel] (no subject)
> -header-y += msr-index.h I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at least four years - and as such it's part of the UAPI. I don't think you can remove it unless you can guarantee there are no userspace users. David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] (no subject)
Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. Exported how? > +#ifdef __INT32_TYPE__ > +#undef __INT32_TYPE__ > +#define __INT32_TYPE__ int > +#endif > + > +#ifdef __UINT32_TYPE__ > +#undef __UINT32_TYPE__ > +#define __UINT32_TYPE__ unsigned int > +#endif > + > +#ifdef __UINTPTR_TYPE__ > +#undef __UINTPTR_TYPE__ > +#define __UINTPTR_TYPE__ unsigned long > +#endif These weren't defined by the kernel before, so why do we need to define them now? Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by changing the signature on C++ functions that use uintptr_t? David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] documentation: Add disclaimer
Paul E. McKenney wrote: > Good point! Would you be willing to add a Signed-off-by so I > can take the combined change, assuming Peter and Will are good > with it? Sure! David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] documentation: Add disclaimer
Peter Zijlstra wrote: > +== > +DISCLAIMER > +== > + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document > is > +meant as a guide to using the various memory barriers provided by Linux, but > +in case of any doubt (and there are many) please ask. > + > +I repeat, this document is not a specification of what Linux expects from > +hardware. The purpose of this document is twofold: (1) to specify the minimum functionality that one can rely on for any particular barrier, and (2) to provide a guide as to how to use the barriers that are available. Note that an architecture can provide more than the minimum requirement for any particular barrier, but if the barrier provides less than that, it is incorrect. Note also that it is possible that a barrier may be a no-op for an architecture because the way that arch works renders an explicit barrier unnecessary in that case. > + Can you bung an extra blank line in here if you have to redo this at all? > + > +CONTENTS > + > > (*) Abstract memory access model. > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel