From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file Date: Wed, 14 May 2008 15:26:33 +0100 Message-ID: <200805141526.34293.paul@codesourcery.com> References: <1210713545-11916-1-git-send-email-aliguori@us.ibm.com> <482ABF6E.6090100@qumranet.com> <482ADA80.3000309@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Fabrice Bellard , Avi Kivity To: qemu-devel@nongnu.org Return-path: In-Reply-To: <482ADA80.3000309@bellard.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org > I suggested it because my original plan for the configuration file was > based on this syntax with a strong inspiration from the OpenFirmware > device tree. The idea was that the object name ("drive" here) had no > hardcoded meaning, except for some predefined object names in order to > keep a kind of backward compatibility with the current QEMU options. In > order to create a new drive for example, you just have to do: > > mydrive.class=drive > mydrive.if=scsi > mydrive.file=abc.img > > the "class" field is used to select the device model. Then all the other > parameters are used to initialize the device model. That way it is > possible to keep the compatibility with the existing options and add a > provision to instanciate arbitrary new device models, such as: I like the idea, but I'm not so keen on the automatic allocation. I generally prefer explicit declaration over implicit things. The latter makes it very easy to not notice when you make a typo. It sounds like what you really want is something similar to an OF device tree. So you have something like: # pciide0 may be an alias (possibly provided by qemu) # e.g. pci0.slot1.func1.ide alias hda ide0.primary.master hda.type=disk hda.file=foo.img You can then define some form of magic aliases that select the next unused device. e.g. alias mydrive $next_ide_disk IMHO This provides the flexibility and structure that Fabrice is talking about, and with suitable aliases can be made to look a lot like the existing options. This may require some internal restructuring to allow the machine descriptions to feed into the user config file. Thoughts? Paul ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/