[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.