10:29 a.m.
1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs
+ 7) / 8 .
2) CPU map cut into standard + extension : It would be more simple to let
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 :
#define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
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 Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau(a)bull.net wrote:
Corrections on proposal:
1) PinVcpus
Replace:
* @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
* @maplen: length of cpumap, in 8-bit bytes
by:
* @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes).
* Each bit set to 1 means that corresponding CPU is usable.
* Bytes are stored in little-endian order: CPU0-7, 8-15...
* In each byte, lowest CPU number is least significant bit.
* @maplen: number of bytes in cpumap, from 1 up to size of CPU map in
* underlying virtualization system (Xen...).
* If maplen < size, missing bytes are set to zero.
* If maplen > size, failure code is returned.
Okay, that's sensible I guess except for maplen it can go from
1 to size + 7 div 8 not up to size , right ?
2) GetVcpu
Add 4rth argument:
* @maplen: number of bytes in cpumap field of virVcpuInfo
virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo,
int maplen)
3) Structure VcpuInfo
Suppress: #define VIR_MAX_CPUS 256
Replace:
unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real
CPUs.
by:
unsigned char cpumap[]; /* Bit map of usable real CPUs.
Variable length: it may be less or greater than size of CPU map
in
underlying virtualization system (Xen...).
Hum, I could see compilers righteously complaining about
unsigned char cpumap[];
in a structure. Maybe we should default to 256 / 8 but allow at the API
level
to grow over that value. What we could do is define a default of 256
available
in the structure and allow an extra parameter which could point to a
larger
array like the following:
- restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256
- virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int
maxinfo,
char *lcpumap, int lmaplen);
lcpumap and lmaplen being extra arguments for very large arrays
for most use case, we will fit in 256 processors, those will be
respectively
NULL and 0, but assuming we have more than 256 processors:
+ maxinfo > VIR_STD_MAX_CPUS
+ lcpumap points to a array of bytes, they are interpreted as an
array of cpumap of ((maxinfo + 7) div 8) bytes each. So
if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an
error.
in that case the cpumap structures of info are not filled on return.
We still have a relatively simple API for the common case, and for
special
cases we have an extension capability with relatively clear definitions.
it's
a bitstrange but I think that should cover most case as best as possible
4) Accessor macros: to be defined later.
okay,
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/
4:11 p.m.
On Tue, Jul 11, 2006 at 05:29:52PM +0200, michel.ponceau(a)bull.net wrote:
2) CPU map cut into standard + extension : It would be more simple to
let
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 :
#define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@
No, I do think it is instead very hard. You start to get into very annoying
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 which
forces that to most users), it expose potential serious problem like alignment
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 itself.
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
--
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/
6710
days inactive
6710
days old
1 comments
2 participants
participants (2)
-
Daniel Veillard -
michel.ponceau＠bull.net