On 03/25/2012 05:26 PM, Anthony Liguori wrote:
Put the emphasis around *configuration*.
So how about:
1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg', '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
2) system-@ARCH@.cfg will contain:
[system] readconfig=@DATADIR@/target-@ARCH@-cpus.cfg readconfig=@DATADIR@/target-@ARCH@-machine.cfg
3) -nodefconfig will not load any configuration files from DATADIR or SYSCONFDIR. -no-user-config will not load any configuration files from SYSCONFDIR.
What, more options? I don't think -nodefconfig (as defined) is usable, since there is no way for the user to tell what it means short of reading those files. -no-user-config is usable, I think it needs also to mean that qemu without -M/-cpu/-m options will error out? since the default machine/cpu types are default configuration.
"#define westmere blah" is not configuration, otherwise the meaning of configuration will drift over time.
-cpu blah is, of course.
It's the same mechanism, but the above would create two classes of default configuration files and then it becomes a question of how they're used.
Confused.
The file defines westmere as an alias for a grab bag of options. Whether it's loaded or not is immaterial, unless someone uses one of the names within.
But you would agree, a management tool should be able to control whether class factories get loaded, right?
No, why? But perhaps I don't entirely get what you mean by "class factories".
Aren't they just implementations of
virtual Device *new_instance(...) = 0?
if so, why not load them?
No, a class factory creates a new type of class. -cpudef will ultimately call type_register() to create a new QOM visible type. From a management tools perspective, the type is no different than a built-in type.
Exactly. The types are no different, so there's no reason to discriminate against types that happen to live in qemu-provided data files vs. qemu code. They aren't instantiated, so we lose nothing by creating the factories (just so long as the factories aren't mass-producing objects).
Otherwise, the meaning of -nodefconfig changes as more stuff is moved out of .c and into .cfg.
What's the problem with this?
The command line becomes unstable if you use -nodefconfig.
-no-user-config solves this but I fully expect libvirt would continue to use -nodefconfig.
I don't see how libvirt can use -nodefconfig with the fluid meaning you attach to it, or what it gains from it.
-nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care.
Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way.
-nodefconfig doesn't mean what you think it means. -nodefconfig doesn't say anything about the user visible machine.
-nodefconfig tells QEMU not to read any configuration files at start up. This has an undefined affect on the user visible machine that depends on the specific version of QEMU.
Then it's broken. How can anyone use something that has an undefined effect? If I see something like -nodefconfig, I assume it will create a bare bones guest that will not depend on any qemu defaults and will be stable across releases. I don't think anyone will understand -nodefconfig to be something version dependent without reading the qemu management tool author's guide. -- error compiling committee.c: too many arguments to function