qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 0/4] Machine config files


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 0/4] Machine config files
Date: Fri, 12 Jun 2009 18:11:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]