qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly


From: Jorge Lucángeli Obes
Subject: Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
Date: Sat, 1 Sep 2007 15:45:13 -0300

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

Cheers,
Jorge




reply via email to

[Prev in Thread] Current Thread [Next in Thread]