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. regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Apr 24, 2007 at 12:41:06AM +0100, John Levon 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. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Apr 24, 2007 at 01:38:10AM +0100, Ewan Mellor wrote:> 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.In terms of 3.0.5 it might be best to indicate nothing is stable for now, so we can work out what we actually need as we go on? regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel