From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNn0j-0005Ac-MD for qemu-devel@nongnu.org; Sun, 04 Mar 2007 04:28:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNn0i-000582-0s for qemu-devel@nongnu.org; Sun, 04 Mar 2007 04:28:09 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNn0h-00057n-Ty for qemu-devel@nongnu.org; Sun, 04 Mar 2007 04:28:07 -0500 Received: from mis011-1.exch011.intermedia.net ([64.78.21.128]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HNn0h-0003tL-IC for qemu-devel@nongnu.org; Sun, 04 Mar 2007 04:28:07 -0500 Message-ID: <45EA9122.6000207@qumranet.com> Date: Sun, 04 Mar 2007 11:28:02 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU/pc and scsi disks References: <45E70CCF.40800@bull.net> <45E7E20A.8020704@bull.net> <20070302110232.GC27636@networkno.de> <200703021542.43161.paul@codesourcery.com> <45E84FB5.2020600@codemonkey.ws> <45E9C605.2090301@qumranet.com> <45EA06EE.3000509@codemonkey.ws> In-Reply-To: <45EA06EE.3000509@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: >> >> 1. Any option should be settable either in the config file or >> command line. In other words, the user should not be forced to use a >> config file. This is useful for management programs who keep all >> options in an internal database, and for users who can experiment via >> a ^P edit edit edit . > > I think we should still provide the ability to set the most common > options via the command line. I'm also fine with specifying single > options on the command line. I suspect though that being able to do > -config - is more useful for management tools than building large > strings of command line options. Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). Of course the config file is very useful for a user maintaining a few virtual machines on their own, but when qemu is part of a longer food chain, I think it's just a complication. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.