11:34 a.m.
On Sun, Mar 25, 2012 at 01:11:04PM -0500, Anthony Liguori wrote:
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 actually prefer -no-user-config, because it gives Qemu freedom to add
more stuff to the outside if needed, but without requiring more
-readconfig options (or -read-something-else options, if we create them)
to be added in the future.
For example, if one day we move machine-types to external files, libvirt
wouldn't have to be changed to add Yet Another -readconfig argument to
make the machine-types available for use. If Qemu moves some device
implementation to external modules, they won't suddenly go away for
users of -no-user-config. The list of possible changes that would break
compatibility for -nodefconfig users but no -no-user-config users is
large.
[...]
>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.
Well, you make the assumption that somebody will every want to use
-nodefconfig the way you want to define it. I don't think nobody will
ever use it if we defined it that way, but that's OK with me. I will
simply ignore the existence of -nodefconfig from now on. :-)
[...]
>>>"#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 distinction _is_ meaningful to libvirt, that's what started this
thread.
[...]
>>>>>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).
And libvirt needs a way to keep module autoloading enabled while
disabling the loading of files from /etc.
You can imagine this being useful for something like Common Criteria certifications.
No problem, except that this is not the use-case libvirt has. If you
want -nodefconfig to mean that, that's OK. But we need an option to just
disable the loading of files from /etc, but keeping loading the "default
non-user-configurable modules that usually are available" (be it CPU
models, machine-types, external modules, whatever), and doesn't keep
changing meaning on every minor release.
[...]
>>>-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.
Then it's not usable by libvirt.
[...]
>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.
Then we need an option with the meaning that libvirt needs, and a
meaning that is stable across releases. If I understood this dicussion
correctly, that would be "-no-user-config".
--
Eduardo