Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:11 PM, Anthony Liguori wrote:
> 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.
If a Fedora user is using qemu, then their qemu version will change
every six months. Their options are to update their scripts/management
tool in step, or not have their management tool use -nodefconfig.
The same holds for anyone using qemu from upstream, since that's
approximately the qemu release cycle.
> -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.
Right.
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.
Definition files should be invisible to users. They're part of the
implementation. If we have a file that says
pc-1.1 = piix + cirrus + memory(128) + ...
then it's nobody's business if it's in a text file or a .c file.
Of course it's nice to allow users to load their own definition files,
but that's strictly a convenience.
> 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.
Okay.
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.
Okay. Let's just make sure to document -nodefconfig as version specific
and -nodefaults as the stable way to create a bare bones guest (and
define exactly what that means).
--
error compiling committee.c: too many arguments to function