Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Andreas Färber]

Am 01.09.2007 um 20:45 schrieb Jorge Lucángeli Obes:

> > And I don't understand why, when going along with the bundle idea,
> > you are suddenly creating a new configuration file format of your
> > own. There is a standard format, XML or text based, which can be
> > easily parsed with OSX APIs (and thus likely *Step APIs as well) as a
> > dictionary, allowing structured information to be stored and thus
> > allowing Qemu backends to store their own settings alongside. See
> > attached one my bundles' configuration.plist file (XML serialized) -
> > relevant is only the Arguments entry, everything else is GUI
> > specific. I'm not saying this format (the structure) were perfect but
> > the underlying "property list" format (key, value-type) is standard
> > for such bundles, so instead of re-inventing the wheel please take a
> > look at how it's being done!
>
> I would like to think that having command line options separated by
> spaces or newlines is a new configuration file format, but it's not.

> This patch is not meant as a replacement for libvirt or any other
> backend. It's just a replacement for shell scripts that serve the only
> purpose of storing command line options. It should be a simple
> solution for a simple problem. The complex solution for the complex
> problem is already there and is called libvirt. I don't want to have
> QEMU parse serialized XML just to replace my '-m 512 -soundhw es1370
> -net nic,model=rtl8139' command line. I would simply like to store
> that command line somewhere.
>
> Anyways, it's obvious that this is a delicate issue for many people
> here. I think the most non-disruptive way of doing this is the '-c'
> command line option. It doesn't change QEMU default behaviour, it
> doesn't add new hyphen-less options. I insist on the fact that this
> should be a simple solution for a simple problem.

What you are basically doing is taking up the concept of a bundle but  
call it directory, do not give it a mandatory folder name extension  
and limit the usefulness of the configuration file to your personal  
needs.

The configuration file format you are proposing is new because you  
are proposing it now while, as one example, Q has previously  
introduced the concept of bundling a Qemu machine on the Mac. And  
the .plist format has existed for bundles even long before that.

Think about it: If you force frontends to use their own configuration  
files inside the bundle because you want to keep yours simple then  
you force frontends to parse two different configuration files.  
Whereas you yourself just said parsing one XML file was already too  
much for you! Standardizing a more advanced configuration file format  
here and now would enable frontends to exchange such bundles,  
retaining their information. By saying you just want a replacement  
for your command line scripts you are ignoring that other people and  
projects may have more advanced needs.

Oh and this has nothing to do with any virtualization libraries,  
virtualization is not what I (or Q) do so that is no solution at all.  
This is all about invoking QEMU.

So in the end it simply means that you are taking an existing concept  
and apply it half-heartedly and short-sighted: I might be wrong but  
it seems you have a *nix viewpoint, are not used to working with  
bundles and therefore re-inventing them differently. There are in  
fact "real" bundles on many Linux systems, have a look at pcsc-lite,  
e.g. /usr/lib/pcsc/drivers/ifd-ccid.bundle. This driver bundle has  
the default extension of .bundle, obviously not being opened as a  
document by a user, but users do start up virtual machines with QEMU  
so a custom extension is useful and necessary to detect that the  
directory represents in fact a bundle and more specifically a QEMU  
machine bundle.

Andreas