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

[<and...@we...>]

Am 01.09.2007 um 20:45 schrieb Jorge Luc=E1ngeli 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=3Drtl8139' 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 =20=

call it directory, do not give it a mandatory folder name extension =20
and limit the usefulness of the configuration file to your personal =20
needs.

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

Think about it: If you force frontends to use their own configuration =20=

files inside the bundle because you want to keep yours simple then =20
you force frontends to parse two different configuration files. =20
Whereas you yourself just said parsing one XML file was already too =20
much for you! Standardizing a more advanced configuration file format =20=

here and now would enable frontends to exchange such bundles, =20
retaining their information. By saying you just want a replacement =20
for your command line scripts you are ignoring that other people and =20
projects may have more advanced needs.

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

This is all about invoking QEMU.

So in the end it simply means that you are taking an existing concept =20=

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

Andreas=