Re: [Xen-devel] [RFC, PATCH] bitops take a long

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

This is a good idea, but...

Several of the changes in public headers are unacceptable as they break 
backward compatibility. Several in the private headers are also 
unacceptable because a shorter type was chosen to fit the space 
constraints of i386 Xen.
Some of these can be got round by casting at point of use (in 
x86-specific code only, of course). Others, like the uint16_t in grant 
tables, will need some more thought. We might need to have 
arch-specific modifiers for that struct, or have arch-specific 
definitions of that struct (so you can make certain fields longs on non 
x86).
This will have to wait until 3.0.2 is properly forked off anyway, then 
we can revisit.
 -- Keir

On 24 Mar 2006, at 17:11, Jimi Xenidis wrote:

> In the spirit of portability and stronger type checking, took one from 
> the pages of Linux and converted all bitops to use "unsigned long *" 
> instead "void *".
> Standardizing on this will also help with ports to architectures that 
> have limited atomic bitop types, especially in the linux code rather 
> than the Xen code.
> Linux did it:
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0204.2/0024.html
>
> Only compile tested.
> Interesting items are:
>   1. vcpu_info_t.evtchn_upcall_pending, is really a boolean of one bit,
>      so perhaps this should be an atomic_t or compare/exchange?
>
>   2. INTER_LEN could be based on long rather that u64
>   3. more use of DECLARE_BITMAP

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel