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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
