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.
Again, defining = #define
Configuring = modifying current instance
>
>> target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
>> the equivalent of
>>
>> #define westmere (x86_def_t) { ... }
>> #define nehalem (x86_def_t) { ... }
>> #define bulldozer (x86_def_t) { ... } // for PC
>>
>> so it should be read at each invocation. On the other hand, pc.cfg and
>> westmere.cfg (as used previously) are shorthand for
>>
>> machine = (QEMUMachine) { ... };
>> cpu = (x86_def_t) { ... };
>>
>> so they should only be read if requested explicitly (or indirectly).
>
> This doesn't make a lot of sense to me. Here's what I'm proposing:
>
> 1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by
> default in /etc/qemu. It would contain:
>
> [system]
> # Load default CPU definitions
> readconfig = @DATADIR@/target-x86_64-cpus.cfg
>
> 2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would
> contain:
>
> [cpudef]
> name = "Westmere"
> ...
>
> This has the following properties:
>
> A) QEMU has no builtin notion of CPU definitions. It just has a "cpu
> factory". -cpudef will create a new class called Westmere that can
> then be enumerated through qom-type-list and created via qom-create.
>
> 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?
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.
>
> 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.
Otherwise, the meaning of -nodefconfig changes as more stuff is moved
out of .c and into .cfg.
>
>>>> The reasoning is, loading target-x86_64-cpus.cfg does not alter the
>>>> current instance's configuration, so reading it doesn't violate
>>>> -nodefconfig.
>>>
>>> I think we have a different view of what -nodefconfig does.
>>>
>>> We have a couple options today:
>>>
>>> -nodefconfig
>>>
>>> Don't read the default configuration files. By default, we read
>>> /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
>>>
>>
>> The latter seems meaningless to avoid reading. It's just a set of
>> #defines, what do you get by not reading it?
>
> 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.
>
>>> -nodefaults
>>>
>>> Don't create default devices.
>>>
>>> -vga none
>>>
>>> Don't create the default VGA device (not covered by -nodefaults).
>>>
>>> With these two options, the semantics you get an absolutely
>>> minimalistic instance of QEMU. Tools like libguestfs really want to
>>> create the simplest guest and do the least amount of processing so the
>>> guest runs as fast as possible.
>>>
>>> It does suck a lot that this isn't a single option. I would much
>>> prefer -nodefaults to be implied by -nodefconfig. Likewise, I would
>>> prefer that -nodefaults implied -vga none.
>>
>> I don't have a qemu.cfg so can't comment on it, but in what way does
>> reading target-x86_64.cfg affect the current instance (that is, why is
>> -nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
>
> It depends on what the user configures it to do.
How?
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.
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list