| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
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
better...
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
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
|
|
| |
|
Home