Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Gleb Natapov <gleb@redhat.com>]

On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
> On 03/25/2012 05:19 AM, Gleb Natapov wrote:
> >On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote:
> >>On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote:
> >>>On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote:
> >>>>On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote:
> >>>>>What does this mean? Will -nodefconfig disable loading of bios.bin,
> >>>>>option roms, keymaps?
> >>>>
> >>>>Correcting myself: loading of _config_ files on /usr/share. ROM images
> >>>>are opaque data to be presented to the guest somehow, just like a disk
> >>>>image or kernel binary. But maybe keymaps will become "configuration"
> >>>>someday, I really don't know.
> >>>>
> >>>Where do you draw the line between "opaque data" and configuration. CPU
> >>>models are also something that is present to a guest somehow.
> >>
> >>Just the fact that it's in a structured key=value format that Qemu
> >>itself will interpret before exposing something to the guest. Yes, it's
> >>a bit arbitrary. If we could make everything "configuration data", we
> >>would (or that's what I think Anthony is pushing for--I hope he will
> >>reply and clarify that).
> >>
> >It is not a "bit arbitrary" it is completely arbitrary.
> 
> It's the Unix Philosophy:
> 
> "Rule of Representation: Fold knowledge into data so program logic
> can be stupid and robust."
> 
> If it can be reasonably represented as data, it should be.  If that
> data can be pushed to a flat text file, it should be.  If you can
> avoid making that special, you should.  This keeps your core logic
> simpler, empowers the user, and creates greater flexibility long
> term.
> 
So you are making my point. You should be able to move data outside of
you code without it becoming user configurable file.

> Your whole argument seems to boil down to: I don't like this--but
> you aren't providing any concrete problems.  It doesn't make it
> harder to write a management tool, it's completely invisible to a
> user, and we have total control over the data files if they're
> stored in /usr/share.
> 
I don't like what? Jugging by above two paragraph I am not so sure you
know. I am for moving cpu model definitions into separate file and putting
it into /usr/share. I am against QEMU not loading it. The reason I am
against it is because the file is not part of a machine configuration
and does not stands by it's own. It depends on combination of QEMU/KVM
and machine definition. You said in this thread that CPU types should be
treated like regular devices by machine type mechanism i.e machine types
should have list of properties for each cpu model which are different
from default.  I do agree with that but how is it going to work if you
do not event have standard model definitions that you can rely on.

> So what's your concrete concern here?  Random comments about kvm
> tool or Gnome 3 are not concrete concerns.  What use-case do you
> think is impacted here and why (and please be specific)?
That are comment about QEMU usability. You do not consider that
important?

> 
> http://en.wikipedia.org/wiki/Unix_philosophy
> 
Nothing there supports your design. Actually I think it contradicts at
least this:
 Rule of Clarity: Clarity is better than cleverness
You try to be clever, but in the end nobody expects CPU models to
disappear just because you asked QEMU to not create default machine.

And you still didn't answer what is your view on current state of
affairs where cpu models in .c files are present while those in separate
file are diaper? So you view it as a bug and is going to make those in
.c files disappear to ?

--
			Gleb.