From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC6cd-0001dz-De for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:54:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SC6cX-00075v-88 for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:53:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC6cX-00075U-0f for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:53:49 -0400 Date: Mon, 26 Mar 2012 11:53:38 +0200 From: Gleb Natapov Message-ID: <20120326095338.GM22368@redhat.com> References: <4F6F1C32.7090801@codemonkey.ws> <4F6F1ED2.6090301@redhat.com> <4F6F2D7D.70500@codemonkey.ws> <4F6F2FB4.5060405@redhat.com> <4F6F32B8.7050401@codemonkey.ws> <4F6F36C7.8010206@redhat.com> <4F6F3941.6040800@codemonkey.ws> <4F6F3C5D.7040802@redhat.com> <4F6F5FB8.2040505@codemonkey.ws> <4F703200.4050008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F703200.4050008@redhat.com> Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Anthony Liguori , qemu-devel@nongnu.org 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.