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

[Jorge Lucángeli Obes]

On 9/1/07, Andreas Färber <address@hidden> wrote:
>
> 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.

I think the problem here is that the scope of this change is not
clear. I _really_ wish to keep this simple. I _really_ wish to avoid
having giant command lines and useless shell scripts. I don't mean to
reinvent the concept of a bundle. Using directories like that seemed a
good way of achieving the purpose of _not_ having to deal with command
lines. Now, it seems that a config file switch is a better choice. I
hardly think that being able to store command line options in a plain
text file is just a matter of _my_ 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.

Those people that have more advanced needs can use the frontends. This
is not meant (necessarily) for frontends. It's meant exactly to
replace command line scripts.

> 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.

libvirt can be perfectly used to invoke QEMU. The name might be
ambiguous, but the functionality is not. In fact, using or not using
KVM with QEMU reduces to selecting a checkbox in libvirt. It's just
another frontend.

> 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.

This is probably true. I never intended to implement the full concept
of a bundle. Again, I was looking for a way to avoid writing gigantic
command lines; a way that would have consensus in the QEMU community.
As I said in my last mail, the config file switch seems more suited to
do this. For what I intended to solve, implementing the whole "bundle"
thing is overkill. I'd rather not move the complexity of the "bundle"
into QEMU, but rather leave it on the frontends. So, let's just have a
simple way of storing command line options in a config file; a way
that does not conflict with existing frontends.

Cheers,
Jorge