[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 11:12:47 UTC 2006

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 

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 Tue, Jul 11, 2006 at 05:29:52PM +0200, michel.ponceau at bull.net wrote:
> 2) CPU map cut into standard + extension : It would be more simple to 
> each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. 

> It could be similar to the version number update, from libvirt.h.in to 
> libvirt.h :

  No, I do think it is instead very hard. You start to get into very 
problems from an API point of view. How do you go from the first element
in the info array to the next one ? in the client it's already not nice,
you must do pointer arithmetic (and I really don't want to push an API 
forces that to most users), it expose potential serious problem like 
and packing, problems between versions of compilers and tools. 
  In a nutshell I don't want an API where one need to access an array of
structure where the size of the structure is not defined by the API 

  What I suggested did that in both case, either low number of CPUs and
fixed size records like you initial solutions, or high number of CPUs and
you work on a two dimentional array of bytes.


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/13320bd7/attachment-0001.htm>

More information about the libvir-list mailing list