Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for event channels

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Feb 28, 2013 at 07:54:26AM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 18:04, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> > --- a/xen/include/asm-arm/types.h
> >> > +++ b/xen/include/asm-arm/types.h
> >> > @@ -41,10 +41,13 @@ typedef char bool_t;
> >> >  #define test_and_clear_bool(b) xchg(&(b), 0)
> >> >  
> >> >  #endif /* __ASSEMBLY__ */
> >> > +#define BYTE_BITORDER  3
> >> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
> >> >  
> >> > -#define BITS_PER_LONG 32
> >> > -#define BYTES_PER_LONG 4
> >> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
> >> >  #define LONG_BYTEORDER 2
> >> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> >> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> >> 
> >> Is that all really correct and complete in the context of arm64 and
> >> an ABI-long not being 32 bits on arm32?
> > 
> > This header is about the internal types, I think, and so should
> > represent the compiler's idea of what the actual long type is for the
> > benefit of common code.
> > 
> > Of course if these are also being used for ABI things, this is a bug on
> > ARM.
> 
> Wei - could you please clarify/double check? I was under the
> impression that these were used e.g. for thing like the event
> channel bit maps and selector words, and those are clearly
> xen_ulong_t, not unsigned long.
> 

Yes, this one needs to be fixed. The whole series was built on top of
Ian's xen_ulong_t patch, but I missed this one. :-(

Also I need to pick up his latest patch.


Wei.

> Thanks, Jan
> 

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