From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCpfg-0006lC-Fk for qemu-devel@nongnu.org; Wed, 28 Mar 2012 06:00:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCpfY-0007P5-EH for qemu-devel@nongnu.org; Wed, 28 Mar 2012 06:00:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCpfY-0007P1-6I for qemu-devel@nongnu.org; Wed, 28 Mar 2012 05:59:56 -0400 Message-ID: <4F72E111.4030505@redhat.com> Date: Wed, 28 Mar 2012 11:59:45 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <4F6B5553.20601@codemonkey.ws> <20120322171445.GJ25451@otherpad.lan.raisama.net> <4F6B850D.9000505@codemonkey.ws> <20120325094920.GJ22368@redhat.com> <4F6F15D2.8000504@codemonkey.ws> <4F6F18E4.2040905@redhat.com> <4F6F19AC.1080009@codemonkey.ws> <4F6F1A50.5090502@redhat.com> <20120325145842.GB11793@redhat.com> <4F6F34AC.2050707@codemonkey.ws> <4F6F375F.6090000@redhat.com> <4F6F3A08.2070609@codemonkey.ws> <4F6F3D97.5010608@redhat.com> <4F6F5D7E.9000808@codemonkey.ws> <4F6F5F6C.9050405@redhat.com> <4F70BCE3.1050201@codemonkey.ws> In-Reply-To: <4F70BCE3.1050201@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org On 03/26/2012 09:00 PM, Anthony Liguori wrote: >>> Yes, that's one reason. But maybe a user wants to have a whole >>> different set of machine types and doesn't care to have the ones we >>> provide. Why prevent a user from doing this? >> >> How are we preventing a user from doing it? In what way is -nodefconfig >> helping it? > > > Let me explain it in a different way, perhaps. > > We launch smbd in QEMU in order to do file sharing over slirp. One of > the historic problems we've had is that we don't assume root > privileges, yet want to be able to run smbd without using any of the > system configuration files. > > You can do this by specify -s with the config file, and then in the > config file you can overload the various default paths (like private > dir, lock dir, etc.). In some cases, earlier versions of smbd didn't > allow you to change private dir. > > You should be able to tell a well behaved tool not to read any > configuration/data files and explicitly tell it where/how to read > them. We cannot exhaustively anticipate every future use case of QEMU. 100% agree. But that says nothing about a text file that defines "westmere" as a set of cpu flags, as long as we allow the user to define "mywestmere" as a different set. That is because target-x86_64.cfg does not configure anything, it just defines a macro, which qemu doesn't force you to use. > > But beyond the justification for -nodefconfig, the fact is that it > exists today, and has a specific semantic. If we want to have a > different semantic, we should introduce a new option (-no-user-config). Sure. -- error compiling committee.c: too many arguments to function