This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft - portability

[oops, resending to list]

On Wed, 2006-06-28 at 11:36 +0100, Ewan Mellor wrote:
> > Actually, that may not matter (assuming the protocol can handle
> > arbitrarily-sized integers). I just checked, and it looks like there
> is
> > a lot of room for capability bits (I'm looking at DOM0_PHYSINFO and
> > __HYPERVISOR_xen_version [the distinction there is not obvious to
> me]).
> > However, I still don't think it makes sense to include bits from all
> > possible architectures in the same namespace, but rather reuse bit
> > positions for each architecture. In other words, capability bit 0 on
> x86
> > could mean something different from capability bit 0 on ia64.
> Would you be happier if we named the constants "X86_FPU" etc, leaving
> room for "PPC_xyz", etc? 

I'm not sure. I was thinking in terms of C bit numbers, because we
hadn't clarified what we really meant by "enum". But now I know

Thinking this through: so when the remote end (xend?) sees "FPU
required", it will need to translate that to a bit number and make an
hcall to query the hypervisor. It can perform that translation because
we're adding an "architecture" field to class VM. Sounds fine.

So no, we don't need to rename any of the bits.

Hollis Blanchard
IBM Linux Technology Center

xen-api mailing list