On 03/25/2012 04:49 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
So let's avoid that and start by having a positive configuration
mechanism that the user can use to change the path and exclude it.
My suggestion eliminate the need for two future command line
options.
If cpu models are not part of configuration they should not be affected
by configuration mechanism. You are just avoiding addressing the real
question that if asked above.
I think you're just refusing to listen.
The stated direction of QEMU, for literally years now, is that we want to arrive
at the following:
QEMU is composed of a series of objects who's relationships can be fully
described by an external configuration file. Much of the current baked in
concepts (like machines) would then become configuration files.
qemu -M pc
Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg
There are some valid points that were raised in this thread, namely that the
user needs to have a file that acts as strictly config (stored in /etc). I'm
totally happy moving the CPU configuration to /usr/share in order to address this.
I think the thread has reduced to: should /usr/share configuration files be read
by default or just treated as additional configuration files. It seems pretty
obvious to me that they should be treated as normal configuration files. This
gives you the user the ability to have fine grain control over which files are
used including the ability to change the location for each file.
Maybe RHEL only wants to expose supported CPUs and supported machines, wouldn't
it be better to not have to patch QEMU to do that?
Wouldn't it be even better if you could drop in a separate CPU configuration
file with the supported CPU types and then change the default /etc config to use
that instead?
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list