On 03/25/2012 04:59 PM, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with definition.
There is no distinction with what we have today. Our configuration file basically corresponds to command line options and as there is no distinction in command line options, there's no distinction in the configuration format.
We don't have command line options for defining, only configuring.
That's an oversight. There should be a -cpudef option. It's a QemuOptsList.
Again, defining = #define
I think -global fits your definition of #define...
Yes (apart from the corner case of modifying a default-instantiated device).
B) A management tool has complete control over cpu definitions without modifying the underlying filesystem. -nodefconfig will prevent it from loading and the management tool can explicitly load the QEMU definition (via -readconfig, potentially using a /dev/fd/N path) or it can define it's own cpu definitions.
Why does -nodefconfig affect anything?
Because -nodefconfig means "don't load *any* default configuration files".
Put the emphasis around *configuration*. "#define westmere blah" is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course.
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?
So what's the mechanism to do this?
C) This model maps to any other type of class factory. Machines will eventually be expressed as a class factory. When we implement this, we would change the default target-x86_64-cpu.cfg to:
[system] # Load default CPU definitions readconfig = @DATADIR@/target-x86_64-cpus.cfg # Load default machines readconfig = @DATADIR@/target-x86_64-machines.cfg
A machine definition would look like:
[machinedef] name = pc-0.15 virtio-blk.class_code = 32 ...
Loading a file based on -cpu doesn't generalize well unless we try to load a definition for any possible QOM type to find the class factory for it. I don't think this is a good idea.
Why not load all class factories? Just don't instantiate any objects.
Unless we have two different config syntaxes, I think it will lead to a lot of confusion. Having some parts of a config file be parsed and others not is fairly strange.
Parse all of them (and make sure all are class factories). The only real configuration item is that without -nodefconfig, we create a -M pc-1.1 system. Everything else derives from that.
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.
In my target-$(ARCH).cfg, I have:
[machine] enable-kvm = "on"
Which means I don't have to use -enable-kvm anymore. But if you look at a tool like libguestfs, start up time is the most important thing so avoiding unnecessary I/O and processing is critical.
So this is definitely configuration (applies to the current instance) as opposed to target-x86_64.cfg, which doesn't.
I'm not sure which part you're responding to..
I was saying that target-x86_64.cfg appears to be definitions, not configuration, and was asking about qemu.cfg (which is configuration).
As far as I can tell, the only difference is that -nodefconfig -cpu westmere will error out instead of working. But if you don't supply -cpu westmere, the configuration is identical.
What configuration?
Let me ask, what do you think the semantics of -nodefconfig should be? I'm not sure I understand what you're advocating for.
-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. -- error compiling committee.c: too many arguments to function