On Tue, Apr 24, 2007 at 01:15:51AM +0100, John Levon wrote:
> 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.
If you would do that, and provide a patch for the docs to say which
names we are relying on, that would be great. I don't think you need to
go overboard and document every bit, but you're right that there are
some key names that people will be looking for wrt live migration (nx,
for example) and it makes sense that we should stabilise these names.
Thanks,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home