From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF9M8-0002U8-Cg for qemu-devel@nongnu.org; Fri, 12 Jun 2009 12:11:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF9M2-0002TQ-Fo for qemu-devel@nongnu.org; Fri, 12 Jun 2009 12:11:50 -0400 Received: from [199.232.76.173] (port=46225 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF9M2-0002TM-B7 for qemu-devel@nongnu.org; Fri, 12 Jun 2009 12:11:46 -0400 Received: from gecko.sbs.de ([194.138.37.40]:16802) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MF9M1-0007Bg-1X for qemu-devel@nongnu.org; Fri, 12 Jun 2009 12:11:46 -0400 Message-ID: <4A327E2C.1060207@siemens.com> Date: Fri, 12 Jun 2009 18:11:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090610173803.4674.82538.stgit@wren.home> <878wjx374h.fsf@pike.pond.sub.org> <4A3269C3.3050307@redhat.com> In-Reply-To: <4A3269C3.3050307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4] Machine config files List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Markus Armbruster , qemu-devel@nongnu.org Gerd Hoffmann wrote: > On 06/12/09 15:37, Markus Armbruster wrote: >> It can be compiled from source with dtc, which doesn't seem to be >> included in the patch series. The language accepted by dtc is pretty >> low-level: it talks NUL-terminates strings, byte strings and arrays of >> "cells" (32 bit integers). > > [ a bunch of examples snipped ] > >> Is that really what we want for a configuration file? > > I do see a point in using fdt as qemu-internal representation. ppc > needs it anyway. It is also a nice way to store the guest configuration > for save/load and migration, you can just send the blob over the wire. > And we can hide the details such as cells behind some nifty helper > functions. > > Qemu users should not be required to be fdt experts though. We need > another, more user-friendly interface to configure virtual machines. > > libfdt has functions to modify the device tree. I think we will need > them to keep the fdt in sync with the machine configuration when > hot-plugging in and out devices (otherwise the fdt is useless for > migration). So when we have code to handle the fdt updates triggered by > the "drive_add ..." monitor command anyway, also handling the -drive > command line switch (or the same input from a more userfriendly machine > config file) should be easy. And if you factor out that code so that a stand-alone tool, say 'qemu-config' could use it too, you would have a way to generate such files: Simply pass the well-known command line switches to that tool and let it generate the corresponding config file for you. That file could then be stuffed into qemu on startup again, maybe temporarily customized by additional command line switches. Of course, the qemu-config tool could also read existing configs and modify them according to the specified wishes. Not having thought too much about this whole topic, such a path sounds quite handy for me, specifically as I do not use fancy front-ends for daily work either. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux