From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBp1G-0006gZ-4w for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:06:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBp1D-0004DP-Ud for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:06:09 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBp1D-0004DI-Nt for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:06:07 -0400 Received: by obbwd20 with SMTP id wd20so4802664obb.4 for ; Sun, 25 Mar 2012 08:06:06 -0700 (PDT) Message-ID: <4F6F345B.1040603@codemonkey.ws> Date: Sun, 25 Mar 2012 10:06:03 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120311151246.GL17882@redhat.com> <4F5CC7AC.6080703@codemonkey.ws> <20120312130810.GB20654@otherpad.lan.raisama.net> <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <20120322133121.GV9375@otherpad.lan.raisama.net> <20120322143055.GI22368@redhat.com> <20120322155018.GY9375@otherpad.lan.raisama.net> <20120325101913.GK22368@redhat.com> <4F6F1911.50500@codemonkey.ws> <20120325144626.GA11793@redhat.com> In-Reply-To: <20120325144626.GA11793@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Avi Kivity , Jiri Denemark , Eduardo Habkost , qemu-devel@nongnu.org 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.