From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF7ze-0005c9-H1 for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:44:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF7zZ-0005Q8-Dx for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:44:33 -0400 Received: from [199.232.76.173] (port=60463 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF7zZ-0005Pc-3V for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:44:29 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45374) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF7zY-0003NA-78 for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:44:29 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5CEiPss010348 for ; Fri, 12 Jun 2009 10:44:25 -0400 Message-ID: <4A3269C3.3050307@redhat.com> Date: Fri, 12 Jun 2009 16:44:19 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] Machine config files References: <20090610173803.4674.82538.stgit@wren.home> <878wjx374h.fsf@pike.pond.sub.org> In-Reply-To: <878wjx374h.fsf@pike.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org 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. cheers, Gerd