[Top][All Lists]

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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

From: Anthony Liguori
Subject: Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Date: Fri, 10 Aug 2007 15:11:18 -0500
User-agent: Thunderbird (X11/20070728)

Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
This is a big effort but a config file is the right long term solution.

For which use case? management-full or management-less?

Both. A config file will be useful not just for expressing the functionality we have today, but also for describing the guest's environment in greater detail. For instance, if you want to support a bunch of different kinds of embedded systems, it would be very nice if the machine description was a config file instead of hard coded such that it was easy to tweak what hardware was present for the particular embedded system.

Maybe I'm dense today.  Which use case is this?

If you're using QEMU to simulate an embedded platform (ARM or PPC based for instance). There is a huge amount of variety in embedded platforms so having to hard code the PC description as a machine type in QEMU is kind of annoying.

A managed system will want to supply arguments out of a central database. For a management-less use case, the config file is a hassle.

As long as all options are still settable via command line (or stdio), then it's not at all a hassle.

Yes.  But if you don't plan to use it, why implement it?

Well, I do plan to use it. I'm simply saying that you don't have to use it if you don't want to.

There are a lot of knobs in QEMU and most of them have somewhat arbitrary defaults. For instance, when I setup a machine, I don't want to use user networking by default, I want to use tap. A global configuration file would be terribly useful for this sort of thing.

My feeling is that config files are outdated. When used with a gui, you end up writing silly parsers and stuff and still wrecking things horribly when the the gui writer's expectations don't match reality. When used without a gui, they increase the amount of details one has to remember (where's that config file? I renamed my image, did I remember to update the config file?). They also make upgrading more difficult.

There's only so much that can be expressed on a command line. There are actually limits to the command line size on a lot of platforms. I don't see why reading options from a file is so much worse than reading them from the command line.


Anthony Liguori

reply via email to

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