On 03/25/2012 10:16 AM, Avi Kivity wrote:
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Avi Kivity wrote:
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.
That's an oversight. There should be a -cpudef option. It's a
QemuOptsList.
Again, defining = #define
I think -global fits your definition of #define...
Yes (apart from the corner case of modifying a default-instantiated device).
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?
Because -nodefconfig means "don't load *any* default configuration
files".
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@xxxxxxxxx
readconfig=@DATADIR@/target-@ARCH@xxxxxxxxxxxx
3) -nodefconfig will not load any configuration files from DATADIR or
SYSCONFDIR. -no-user-config will not load any configuration files from SYSCONFDIR.
"#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.
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.
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.
I'm not sure which part you're responding to..
I was saying that target-x86_64.cfg appears to be definitions, not
configuration, and was asking about qemu.cfg (which is configuration).
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.
What configuration?
Let me ask, what do you think the semantics of -nodefconfig should
be? I'm not sure I understand what you're advocating for.
-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.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list