10:16 a.m.
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(a)/target-x86_64-cpus.cfg
>> # Load default machines
>> readconfig = @DATADIR(a)/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