On Mon, Jun 26, 2006 at 01:31:24PM -0500, Hollis Blanchard wrote:
> [Snip: Re: CPU feature flags]
>
> I didn't realize these features will be exposed in the user interface at
> all. How do you expect that to work? (I explained the only scenario that
> I could see: "I created a domain here, and now I want to know if I can
> move it over there.")
The other use case is "Please don't expose these features to my VM, because I
will need to be able to move it over there later".
> Also, do you expect non-specialist users to manage terms like "CX8",
> "PSE36", ...?
That's a good question, but one I hope to solve at the UI, not the API. Maybe
your cluster manager knows what machines you have in your hetrogenous cluster,
and so can manage these flags for you?
> - Do you expect higher-level software to hardcode a list of these
> features for the UI? That's a problem both for portability and for
> future x86 architectures (with currently undefined feature bits). How
> can we avoid that?
I expect us to define a set of strings that are known and understood to have
particular semantics, so that higher level software can manage them. I don't
think that we can manage these flags correctly otherwise. I don't see this as
a problem for portability -- I hope to be able to define the appropriate
strings for PPC as well as for x86. For flags that we don't yet know about,
for platforms that we're not working with at the moment, say, or new flags on
existing platforms, we would add these to the set of known strings. New
clients would be fine -- old clients would have to say to the user "I've no
idea what this value 'PSE79' is, should I leave it alone?" (or the client
software could just leave it alone silently).
> - Is an "enum" here a list of strings? If not, there is danger of
> running out of bit numbers in a fixed-size bitmask. It's worth pointing
> out that you've already listed 63 enum items.
On the wire, a particular value of an enum is a string, yes.
> - Do you agree that it makes sense to add "architecture" and "compatible
> architectures" fields to class VM and host_cpu, respectively?
I certainly agree that we need to handle non-x86 platforms, but I'm not sure
what that entails.
I don't have a problem adding "architecture" to VM, that sounds like something
you'd want to know anyway. Does having "compatible architectures" on the
Host_cpu class make sense, as opposed to having it on Host? Do we want to
model a machine with different CPU architectures?
If we fix these things, are these fields sufficient for PPC support?
Cheers,
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home