On Tue, Apr 24, 2007 at 12:47:36AM +0100, Ewan Mellor wrote:
> > The functions to return 'features' and 'flags' in the Xen API seem a
> > little under-specified, in particular there's no indication of the
> > format of the string returned. Presumably at some point something is
> > going to use them. At which point the user has an interesting problem if
> > it's relying on something there and it's not present.
> >
> > Either this return value needs to be explicitly labelled as not reliable
> > or something needs to be defined as 'architectural' for Xen API.
>
> Yes, these are 'architectural'. For x86, host_cpu.features is the same
> format as you get from xm info's hw_caps field, and host_cpu.flags is a
> readable version of that (we get it from /proc/cpuinfo). Other
> architectures are free to define appropriate equivalents.
I suppose I wasn't clear. If they're not defined in the API they can't
be relied upon, this is the nature of a stable API. It's not good enough
for a specification to say "look over there" when it points to an
unstable, undocumented interface.
In particular I presume that we're going to end up with some version of
the Linux cpuinfo names for the flags. That's OK, but they need to be
clearly defined, or clearly labelled as unreliable. It'd be OK to list
some of them with stable names and others as unreliable, of course.
The reason I'm asking is we're going to have to implement the flags for
Solaris. The simplest way to do this is to use the same names as we have
for our equivalent of "grep flags /proc/cpuinfo", which is isainfo -x:
$ isainfo -x
amd64: ahf sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 tsc fpu
i386: ahf sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 tsc fpu
Now, this is great if it's just informative, but worse than useless if
clients need to rely on responses. And given live migration, they will
do. I don't mind taking on the tedious job of writing the code to
translate from what Solaris can provide into Linux names, but there
absolutely needs to be stable, reliable mapping for this to work.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home