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