| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC, PATCH] bitops take a long
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
|
|
|
| |
|
Home