[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt

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

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.


>>>> 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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]