[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line

From: Christian Brunschen
Subject: Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
Date: Sat, 11 Aug 2007 20:08:22 +0100

On 11 Aug 2007, at 19:06, Philip Boulain wrote:

Yikes. I like the intent, but the idea of a previously just-data file format suddenly being able to imply "-hdb fat:rw:/home/" does not strike me as a good one. :/

Hi all,

I'm nobody in particular in the world of qemu, and have certainly never contributed to it, but I hope you won't mind if I mention some thoughts.

It seems to me that overloading a simple data format to suddenly also include metadata is indeed a decision fraught with potential for unhappiness.

Much better would be to perhaps devise a container format that would embed a qemu configuration as well as a number of disk image files. Of course, to have such ini a single file is not necessarily very easy. However, one need only look at NeXTSTEP/OPENSTEP/Mac OS X to see a solution: use a directory.

Basically, one way to bundle a machine configuration together yet leave existing file formats unchanged is to define a standard directory structure that can contain a qemu configuration file (a set of command line options) as well as a number of related files (mainly disk images, but could also me BIOS ROM or similar of course). It doesn't need to be a complex structure: simply specify that a 'qemu machine directory' contains a file named 'config.qemu' in a specific format (with file references relative to the directory containing config.qemu). qemu, if given as its sole command line option the name of a directory, checks whether the directory contains a suitable config.qemu, and reads & process the file as if it were command line options (with the current directory.

Such a directory can be kept entirely platform independent, such that the entire directory could be moved or copied from one host to another. It would mean perhaps tar:ing or zip:ing it up, but certainly on Mac OS X such directories have proven to be a successful way of bundling things together (certainly helped by the widespread use of disk image files, through which distributing directories becomes entirely a non-problem).

Something like that _should_ offer most of the features that people want - a simple way to encapsulate both configuration and data, platform-independent, short and sweet to specify on the command line, without making any changes to existing file formats (particularly disk image ones).

Just a thought,

// Christian Brunschen

reply via email to

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