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@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. 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. Confused. > >>>> 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 effect? 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list