I imagined that each Libvirt user could choose its own MAX number of CPU. If it is not possible, at least can we reserve the extended cpumap for future development (TODO, same as NULL domain pointer) ? Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Thu, Jul 13, 2006 at 01:12:47PM +0200, michel.ponceau(a)bull.net wrote: by sizeof(virVcpuInfo)when Well if you need to recompile the library to use a larger set of CPU you don't garantee API and ABI, by definition. And you will need to recompile the library because the structures passed between the app and the library change size, this will also likely affect the proxy since I expect vCPU informations to be provided (so communication between the library and proxy must change). There is certainly solutions to the scalability problem, but suggesting a change of header and recompilation of the whole software stack is really not one I would like to propose, it breaks basically all expectations an enterprise customer would have w.r.t. using the library. Unless I really misunderstood what you were suggesting, which is possible in that case reformulating it might be a good idea, because I really understood you want to make the MAX number of CPU a compile time setting. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/