On Mon, Mar 26, 2012 at 11:08:16AM +0200, Avi Kivity wrote:
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.
Modularised minimal QEMU may be a good thing, but how -nodefconfig helps here? Won't you have the same effect if QEMU will load modules on demand, only when they are actually needed (regardless of -nodefconfig). i.e virtio-blk is loaded only if there is -device virtio-blk somewhere in configuration.
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).
What is the reason libvirt uses -nodefconfig instead of -nodefaults now? What the former does for them that the later doesn't? -- Gleb.