[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs

michel.ponceau at bull.net michel.ponceau at bull.net
Thu Jul 13 12:11:57 UTC 2006


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 at redhat.com
Pour :  michel.ponceau at bull.net
cc :    libvir-list at 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 at bull.net wrote:
> I don't understand. Libvirt users must of course compile API and 
> application with the same libvirt.h, after updating the value of 
> VIR_MAX_CPUS when necessary. And go from first info element to next one 
by 
> (info+1), which adds sizeof(virVcpuInfo) to address, including correct 
> length of cpumap according to:
>     unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable 
> real CPUs.
> For alignment constraints, compiler rounds up the 
sizeof(virVcpuInfo)when 
> needed.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060713/fdf06c6e/attachment-0001.htm>


More information about the libvir-list mailing list