Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Christian Brunschen wrote:
>
> On 17 Aug 2007, at 13:40, Avi Kivity wrote:
>
>> It's not easy to use: if you move the image, you need to move the file.
>> I'd like to have exactly one entity to worry about when using a virtual
>> machine.
>
> As I wrote previously, there is already such a thing on every modern 
> operating system, one entity that can be used to wrap several others: 
> it's a directory. Putting things together into a directory, and then 
> treating that directory as a single entity, is a tried and tested 
> technique (in particular in NeXTStep and its successors, up to and 
> including Mac OS X).
>
> Simply put, I think that it makes excellent sense to keep the data 
> (disk image) and the metadata (qemu configuration) separate, at least 
> in this particular case where keeping the data separate makes it more 
> easily reusable. Specifically, disk images that are simply disk images 
> are much more likely to be usable by more than one emulator / virtual 
> machine, than some other file format that combines a disk image with 
> some metadata that is going to be fundamentally non-portable and 
> indeed specific to one emulator or vm.
>
> As I see it, the easiest and most portable thing to do is to define a 
> simple file format that qemu can use for its configuration. Place the 
> configuration file and the associated disk image(s) together in the 
> same directory, and you have created a single entity that includes 
> both the data and the metadata. Add a little bit of functionality to 
> the emulatir, such that if it is given as a suitable argument the name 
> of a directory, then look for the configuration file at a specific 
> name in that directory, and only allow references from that config 
> file to other files in that directory (thus enforcing the 
> encapsulation). Now you have a system where you can either keep things 
> completely manual (specify everything on the command line, automated 
> but separate (specify the configuration file and have it explicitly 
> reference full paths) or automated and encapsulated (data and metadata 
> all kept together in a single container). And all of this without 
> having to change the formats of any existing files, all without 
> introducing any backwards incompatibility.
>

It does make a lot of sense.  The only drawbacks I can find are:
- you can't directly execute the directory
- this deviates from standard Unix (and Windows) practice.  Arguably the 
OS X way is superior, but qemu is perhaps not the best vehicle to 
introduce it to other OSes.

While this implementation won't be my first choice, I find it acceptable 
and good enough for my use case.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/