On Thu, Oct 18, 2007 at 04:53:15AM -0400, Daniel Veillard wrote:
On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
> This is certainly a nit, but I might change parseCpuNumber to
> parseNumber, since it looks a little odd that you are getting the cell
> id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu,
which doesn't make that much sense. Since we are testing against
maxcpu I really think we should keep the function name, I can
duplicate code and make a simpler function just for parsing the
cell no.
> Other than our discussion on #virt about handling of ^N specifications
> in parseCpuSet, looks good!
Which is done in my version, will propagate.
New version with the changes suggested. Also the dump exercize the
serialization code ifor CPUset (see the new <dump> elements which won't
be used in the final code but useful to check correctness of output)
Valgrind tst allowed me to found a bug in virBufferContentAndFree()
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/