| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [RFC] Re: [Xen-devel] [PATCH] fix xenctl_cpumap translation to handl
On Jan 17, 2007, at 7:20 AM, Keir Fraser wrote:
On 16/1/07 23:26, "Jimi Xenidis" <jimix@xxxxxxxxxxxxxx> wrote:
Sorry for taking so long with this, please comment on the following:
The following patch adds the ability to convert form "long" based
bitmaps to "byte" base bitmaps for portability. This is only has the
hypervisor side, but the definitions are such that the same prototype
can be use by XC and Xen.
Sadly it adds a copy on the xenctl_cpumap_to_cpumask(), but it
minimally
impacts the common paths.
Fine interface. On the Xen side the prototypes should go in xen/
bitmap.h and
the implementations in common/bitmap.c.
Ack
I've added the Linux byteorder
functions so in bitmap.c you ifdef on __BIG_ENDIAN and then use
le32_to_cpu
or le64_to_cpu (depending on BITS_PER_LONG).
Ack
There's a question over whether
we should do this transformation in-place on the bitmap, or use the
copying
semantics that you've chosen. I guess the latter is cleaner.
A copy will almost always be necessary since the source or
destination (always the long) may actually be active and could have
come from anywhere, where the byte is most likely local.
Actually, your
'no-op' long_to_byte_bitmap() implementation does not memcpy -- why
is that?
This is a little (possibly dirty) attempt to avoid a copy if no
conversion is required.
As long as the caller uses the return value all is well.
I'd happy to make it a memcpy() and feel better about it.
On the guest side you'll need to dup the function prototypes and
implementations in libxenctrl. Trying to share prototypes or
anything via
the public headers is just skanky. Add a comment to xenctl_cpumap
to explain
the format (explain it is 'little endian' or 'byte oriented' with
an ascii
diagram) and leave it at that.
Ack
-JX
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home