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