[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.