[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |