From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJapS-0007vJ-Od for qemu-devel@nongnu.org; Fri, 10 Aug 2007 16:11:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJapN-0007kl-V8 for qemu-devel@nongnu.org; Fri, 10 Aug 2007 16:11:26 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJapN-0007kX-IZ for qemu-devel@nongnu.org; Fri, 10 Aug 2007 16:11:21 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJapN-0008CY-4C for qemu-devel@nongnu.org; Fri, 10 Aug 2007 16:11:21 -0400 Received: by wr-out-0506.google.com with SMTP id c38so257373wra for ; Fri, 10 Aug 2007 13:11:20 -0700 (PDT) Message-ID: <46BCC666.6050406@codemonkey.ws> Date: Fri, 10 Aug 2007 15:11:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images References: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> <46BC8C18.6020108@codemonkey.ws> <46BC9CDB.3080900@qumranet.com> <46BCB1DA.6060102@codemonkey.ws> <46BCBF73.5060406@qumranet.com> In-Reply-To: <46BCBF73.5060406@qumranet.com> 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: Avi Kivity Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>>> This is a big effort but a config file is the right long term >>>> solution. >>>> >>>> >>> >>> For which use case? management-full or management-less? >>> >> >> Both. A config file will be useful not just for expressing the >> functionality we have today, but also for describing the guest's >> environment in greater detail. For instance, if you want to support >> a bunch of different kinds of embedded systems, it would be very nice >> if the machine description was a config file instead of hard coded >> such that it was easy to tweak what hardware was present for the >> particular embedded system. >> > > Maybe I'm dense today. Which use case is this? If you're using QEMU to simulate an embedded platform (ARM or PPC based for instance). There is a huge amount of variety in embedded platforms so having to hard code the PC description as a machine type in QEMU is kind of annoying. >>> A managed system will want to supply arguments out of a central >>> database. For a management-less use case, the config file is a hassle. >>> >> >> As long as all options are still settable via command line (or >> stdio), then it's not at all a hassle. >> > > Yes. But if you don't plan to use it, why implement it? Well, I do plan to use it. I'm simply saying that you don't have to use it if you don't want to. There are a lot of knobs in QEMU and most of them have somewhat arbitrary defaults. For instance, when I setup a machine, I don't want to use user networking by default, I want to use tap. A global configuration file would be terribly useful for this sort of thing. > My feeling is that config files are outdated. When used with a gui, > you end up writing silly parsers and stuff and still wrecking things > horribly when the the gui writer's expectations don't match reality. > When used without a gui, they increase the amount of details one has > to remember (where's that config file? I renamed my image, did I > remember to update the config file?). They also make upgrading more > difficult. There's only so much that can be expressed on a command line. There are actually limits to the command line size on a lot of platforms. I don't see why reading options from a file is so much worse than reading them from the command line. Regards, Anthony Liguori > > >