From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JwIbZ-0000uJ-M6 for qemu-devel@nongnu.org; Wed, 14 May 2008 11:09:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JwIbY-0000tv-68 for qemu-devel@nongnu.org; Wed, 14 May 2008 11:09:21 -0400 Received: from [199.232.76.173] (port=50176 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwIbX-0000ts-ON for qemu-devel@nongnu.org; Wed, 14 May 2008 11:09:19 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:37040) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JwIbX-0001sM-Hf for qemu-devel@nongnu.org; Wed, 14 May 2008 11:09:19 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4EFBTro016818 for ; Wed, 14 May 2008 11:11:29 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4EF9Ial106848 for ; Wed, 14 May 2008 11:09:18 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4EF9HBl004170 for ; Wed, 14 May 2008 11:09:18 -0400 Message-ID: <482B009C.2070101@us.ibm.com> Date: Wed, 14 May 2008 10:09:16 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file References: <1210713545-11916-1-git-send-email-aliguori@us.ibm.com> <482ABF6E.6090100@qumranet.com> <482ADA80.3000309@bellard.org> <200805141526.34293.paul@codesourcery.com> In-Reply-To: <200805141526.34293.paul@codesourcery.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: Paul Brook Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org Paul Brook wrote: >> 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 > What I don't like about the ide0.primary.master syntax is that there isn't enough structure. I would prefer: alias hda ide,bus=0,primary,master If you combine this with your magic variable idea, you could also do: alias hda ide,bus=0,unit=$next But you could also just fold that into Fabrice's syntax (which I prefer): hda.class = ide,bus=0,unit=$next hda.type = disk hda.file = foo.img If you then default bus, and unit, you can just write: hda.class = ide hda.type = disk hda.file = foo.img And better yet, you could even allow for something like: hda.class = ide hda.bus = 0 hda.unit = 0 hda.type = disk hda.file = foo.img So I really actually prefer Fabrice's syntax because there is much more structure. I think it's a good idea to allow .class to contain multiple properties and to basically establish an alias. This way, you could predefine a bunch of aliases for today's parameters like hda, hdb, etc. > 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. > I think if we choose a syntax we like, we can start using that pretty easily. We'll have to start adjusting option names keeping them only valid on the command line (for things like -m). However, I think it would grow pretty well into a machine description mechanism. Regards, Anthony Liguori > Thoughts? > > Paul >