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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/