On 09/16/10 12:45, Ian Campbell wrote:
On Wed, 2010-09-15 at 08:26 +0100, Juergen Gross wrote:
attached patch implements cpupool support in xl. Rewrite of previous patch
after rework of libxl.
Please could you provide a changelog message? It seems you needed to
modify the libxc interface in order to support libxl, it would be worth
commenting on what/why you changed.
In several places I notice you calculate (X + 64) / 64. Normally I would
expect a (X + 63) / 64 pattern to round something up (for example in
other places you use + 7 / 8). Is this deliberate? Probably worth a
comment, or maybe wrap the concept into a function with an appropriate
This was the conversion from max_cpu_id (which is 1 less than the max
number of cpus) to the number of map elements. I've moved this to an own
function for allocating a cpumap.map.
I think the units of libxl_cpumap.size might be worth a comment too,
especially since appears to differ from the units used in the libxc
interface. You can do this in the IDL with e.g.
- ("size", uint32),
+ ("size", uint32, False, "number of<bananas> in map"),
I think<bananas>=="uint64_t sized words"? Perhaps size would be better
represented as the maximum CPU ID in the map? The fact that the map is
rounded up to the next 64 bit boundary isn't too interesting to callers,
I kept your proposal to keep the size in bytes (like in xc).
I saw a "size * 8" which I think would better as "size *
The 8 is the number of bits in a byte (size being number of bytes).
Similarly callers seem to be doing "map[i / 64]& (i %64)" type
arithmetic, I think providing a libxl_cpumap_cpu_present helper (and
_set/_clear if necessary) would help here.
Done that, too.
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28 Internet: ts.fujitsu.com
D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
Description: Text Data
Xen-devel mailing list