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
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 saw a "size * 8" which I think would better as "size *
sizeof(*....map)", although perhaps this usage reinforces the idea that
the size should be in CPUs not multiples of some word size? Especially
given that this is seen in the caller who I guess shouldn't really need
to know these details.
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.
Xen-devel mailing list