Re: [RFC] Re: [Xen-devel] [PATCH] fix xenctl_cpumap translation to handle bitops accessed like arrays

[Keir Fraser <keir@xxxxxxxxxxxxx>]

On 21/12/06 5:32 pm, "Jimi Xenidis" <jimix@xxxxxxxxxxxxxx> wrote:

>> How about functions long_to_byte_bitmap(bitmap, nr_bits) and
>> byte_to_long_bitmap(bitmap, nr_bits) defined in asm/bitops.h?
> 
> hmm, as I see it we have 3 interfaces that should remain compatible.
>   1) The hvcall which uses a byte array
>   2) The libxc calls where 2 use uint64_t and one uses uint32_t
>   3) The xm/xc.c call which constructs a python list using "C"
> ordering of the uint*_t word
> 
> so we would need similar interfaces in libxc and we would need a
> byte_to_uint{64,32}(), unless you want to change the libxc interfaces
> as well.

I am suggesting we change just the hypervisor interface to expect a
byte-oriented bitmap. So the libxc interfaces can stay as they are, but the
libxc functions will need to do conversion from uint32_t/uint64_t to a
byte-oriented bitmap. There is no loss of backward compatibility here for
ia64 or x86 as little-endian systems do not care whether a bitmap is byte-
word- or longword-oriented -- they're all identical.

> I see now (I'm not that familiar with x86) that bitops in x86 are
> "consistent" with "C" shifting so x86 experience no change, however
> is it worth optimizing this?

The way you are doing the conversion would be fine. I'm mainly aiming for a
clean abstraction and formalising the concept of a 'byte-oriented bitmap' is
the best way of doing this that I can see right now.

 -- Keir


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