Re: [Qemu-devel] [Patch v1 01/29] qmp: details about CPU definitions in query-cpu-definitions

[David Hildenbrand <dahi@linux.vnet.ibm.com>]

> On Tue, Aug 02, 2016 at 04:27:55PM +0200, David Hildenbrand wrote:
> [...]
> > > > > 
> > > > > I believe in this case we don't need to make it optional: just
> > > > > make the field always present and set it to "false" by default.    
> > > > 
> > > > That is true for x86, do you know about the other architectures (arm, ppc)?
> > > > I'd like to avoid returning false information here for other architectures.    
> > > 
> > > As being "static" is not a fact about the existing code, but just
> > > a guarantee about what the developers are going to do in the
> > > future, static=false just means that the developers didn't make
> > > any promises yet (so I don't think it would ever be false
> > > information).
> > > 
> > > In other words, I believe we can safely assume a CPU model is not
> > > guaranteed to be static unless the maintainers decided to
> > > explicitly document it as static (and change the data returned by
> > > query-cpu-definitions).
> > > 
> > > (I am assuming that changing it from "false" to "true" in a new
> > > QEMU version won't be a problem for anybody.)
> > >   
> > 
> > Hmm, if "static" means, the model will never be changed, but it was changed in
> > the past, this sounds somewhat strange. I would rather say then "information
> > is not available" == no guarantee.  
> 
> If the CPU model really changed in the past, I think it must be
> always set to "false".
> 
> But if it never changed in the past and we never made an explicit
> decision about future guarantees, we can set it to "false" today,
> and change it to "true" later (after we made a decision).
> 
> > 
> > But if nobody else sees a problem with that, I can just set it to stable=false
> > on all other architectures.  
> 
> I think it's OK, as long we set it to "true" only if it never
> changed in the past.
> 

That indeed is okay. So I'll change that for arm,ppc and x86 (static=false for
all returned definitions).

David