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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/25/2012 09:46 AM, Gleb Natapov wrote:
> On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
>> On 03/25/2012 05:19 AM, Gleb Natapov wrote:
>> 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.

You're reading words that don't exist.

>> 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?

User configuration apparently.

> 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.

Why are you trying to prevent a user from being able to control what QEMU does?

> 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.

This is not a concrete argument.  It assumes that there's an agreed upon concept 
of "machine configuration" and "stands by it's own" which there obviously isn't.

What is the concrete technical or use-case argument here beyond that it doesn't 
match a concept that you have in your head of how things should be?

> 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.

Who is "you"?  QEMU will provide a list of models in /usr/share that are loaded 
by default.  If you actively disable it by using -nodefconfig, you're on your 
own.  I would personally never use -nodefconfig.  The only user of -nodefconfig 
is a management tool that is purposefully trying to make QEMU do the 
minimalistic amount of things possible.

I'm not sympathetic to arguments that user's are stupid and you have to keep 
them from doing things they shouldn't.  Defaults should Just Work and simple 
things should be simple to do.  But if a user expressly tells QEMU not to enable 
defaults, then they should know what they're doing.

>> 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.

It's not clever to me, it's obvious.

> 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?

This is strictly a compatibility issue.  At this point in time, we could move 
the .c definitions to a configuration file as we've gone through enough releases 
with the default configuration file present.

> So you view it as a bug and is going to make those in
> .c files disappear to ?

Absolutely.

Regards,

Anthony Liguori

> --
> 			Gleb.