From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnCa-0007UU-3Q for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:09:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBnCY-0000Jv-2y for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:09:43 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:47583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnCX-0000Jg-Uw for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:09:42 -0400 Received: by obbwd20 with SMTP id wd20so4713892obb.4 for ; Sun, 25 Mar 2012 06:09:40 -0700 (PDT) Message-ID: <4F6F1911.50500@codemonkey.ws> Date: Sun, 25 Mar 2012 08:09:37 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120311124116.GI17882@redhat.com> <4F5CB3D1.4050100@codemonkey.ws> <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> In-Reply-To: <20120325101913.GK22368@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 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. 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. 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)? http://en.wikipedia.org/wiki/Unix_philosophy Regards, Anthony Liguori