From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJx29-00087J-0W for qemu-devel@nongnu.org; Sat, 11 Aug 2007 15:54:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJx27-00086p-FS for qemu-devel@nongnu.org; Sat, 11 Aug 2007 15:54:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJx27-00086m-BO for qemu-devel@nongnu.org; Sat, 11 Aug 2007 15:53:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJx26-0004FP-TE for qemu-devel@nongnu.org; Sat, 11 Aug 2007 15:53:59 -0400 Received: by wx-out-0506.google.com with SMTP id h31so846683wxd for ; Sat, 11 Aug 2007 12:53:58 -0700 (PDT) Message-ID: <46BE13D4.6090702@codemonkey.ws> Date: Sat, 11 Aug 2007 14:53:56 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images References: <59abf66e0708081124g14901b01i841b70d17ae1e097@mail.gmail.com> <59abf66e0708081252of2948d7we85c9084bad245d4@mail.gmail.com> <46BDFA90.4070400@ecs.soton.ac.uk> In-Reply-To: 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: qemu-devel@nongnu.org Christian Brunschen wrote: > > 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. I expect we'll see something like this emerge in the future. Regards, ANthonY Liguori > 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 > > > >