On Mon, Jun 26, 2006 at 03:22:15PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 26, 2006 at 04:14:59PM +0200, michel.ponceau@xxxxxxxx wrote:
> > 2) For "xm vcpu-list" equivalent function (suggested virDomainGetVcpus) I propose to return in a new structure all the information provided by
> > Xen Daemon. I am trying the following addition in libvirt.h :
> > typedef struct _virVcpuInfo virVcpuInfo;
> > struct _virVcpuInfo {
> > int number; /* virtual CPU number */
> > unsigned char state; /* 'r'=running, 'b'=blocked, 'p'=offline
> > */
> > unsigned long long cpuTime; /* CPU time used, in nanoseconds */
> > int cpu; /* last real CPU number allocated */
> > char cpumap[128]; /* affinity map of real CPUs which can be
> > allocated */
> > };
> > typedef virVcpuInfo *virVcpuInfoPtr;
> >
> > For cpumap, the xm command displays a string "x,y-z..." more compact than
> > the list of all possible CPUs "x y y+1 y+2...z..." provided by xend. But
> > the routines for this reformatting are not easy, so I propose to keep the
> > xend format in virCpuInfo. What is your opinion?
>
> That is a rather unpleasent format to expose to applications - each application
> will be forced to write their own (buggy) parser to extract useful information
> from this string. It really needs to be sructured in a format which can be
> directly interpreted, without requiring parsing.
Hum, I missed that. Agreed, do not use a string, we should use an array.
The virVcpuInfo structure will be allocated by the client, make sure it is
extensible to whatever the need might be in the future. Say you have a
box with 1024 CPU, ideally the client should be able to call libvirt and
specify any combination of those. Also let's check what is the low level
hypervisor interface there.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/