1:11 p.m.
On 03/25/2012 10:40 AM, Avi Kivity wrote:
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
>> Put the emphasis around *configuration*.
>
>
> So how about:
>
> 1) Load ['@SYSCONFDIR(a)/qemu/qemu.cfg',
> '@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
> '@DATADIR(a)/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
>
> 2) system-@ARCH@.cfg will contain:
>
> [system]
> readconfig=@DATADIR@/target-@ARCH(a)-cpus.cfg
> readconfig=@DATADIR@/target-@ARCH(a)-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?
Okay, we can just drop -no-user-config and then if a management tool wants to do
the equivalent, they can do -nodefconfig + '-readconfig
@DATADIR@/system-@ARCH@.cfg'. I'm equally happy with that :-)
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.
*if the user doesn't know specifics about this QEMU version.
You make the assumption that all users are going to throw arbitrary options at
arbitrary QEMU versions. That's certainly an important use-case but it's not
the only one.
-no-user-config is usable, I think it needs also to mean that qemu
without -M/-cpu/-m options will error out?
You're confusing -nodefaults (or something stronger than -nodefaults) with
-no-user-config.
Yes, the distinctions are confusing. It's not all fixable tomorrow. If we take
my config refactoring series, we can get 90% of the way there soon but Paolo has
a more thorough refactoring..
>> "#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.
We don't have a formal concept of -read-definition-config and
-read-configuration-config
There's no easy or obvious way to create such a concept either nor do I think
the distinction is meaningful to users.
>>>> 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).
At some point, I'd like to have type modules that are shared objects. I'd like
QEMU to start with almost no builtin types and allow the user to configure which
modules get loaded.
In the long term, I'd like QEMU to be a small, robust core with the vast
majority of code relegated to modules with the user ultimately in control of
module loading.
Yes, I'd want some module autoloading system but there should always be a way to
launch QEMU without loading any modules and then load a very specific set of
modules (as defined by the user).
You can imagine this being useful for something like Common Criteria certifications.
>>>> 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?
It's obviously defined for a given release, just not defined long term.
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.
That's not even close to what -nodefconfig is. That's pretty much what
-nodefaults is but -nodefaults has also had a fluid definition historically.
Regards,
Anthony Liguori
I don't think anyone will understand -nodefconfig to
be something version dependent without reading the qemu management tool
author's guide.