From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8isE-0005Ly-Qg for qemu-devel@nongnu.org; Fri, 05 Dec 2008 17:10:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8isE-0005Lj-8O for qemu-devel@nongnu.org; Fri, 05 Dec 2008 17:10:10 -0500 Received: from [199.232.76.173] (port=36823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8isE-0005Lf-04 for qemu-devel@nongnu.org; Fri, 05 Dec 2008 17:10:10 -0500 Received: from bart.se.axis.com ([195.60.68.10]:58048) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L8isD-0006rw-LB for qemu-devel@nongnu.org; Fri, 05 Dec 2008 17:10:09 -0500 Received: from bart.se.axis.com (bart.se.axis.com [127.0.0.1]) by bart.se.axis.com (Postfix) with ESMTP id B0C74641F1 for ; Fri, 5 Dec 2008 23:10:07 +0100 (CET) Received: from axis.com (edgar.se.axis.com [10.93.151.1]) by bart.se.axis.com (Postfix) with ESMTP id 937AD641DB for ; Fri, 5 Dec 2008 23:10:07 +0100 (CET) Date: Fri, 5 Dec 2008 23:10:07 +0100 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] Modular qemu? Message-ID: <20081205221007.GB25555@edgar.se.axis.com> References: <3056442136ca43729c6a2aec02c038aa.squirrel@www.boonen.name> <49393B8D.40209@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49393B8D.40209@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, Dec 05, 2008 at 08:32:45AM -0600, Anthony Liguori wrote: > Joop Boonen wrote: >> Hello All, >> >> I'm wondering if a modular qemu would be an option (loadable modules)? >> Currently a lot different patched versions of qemu are around. >> qemu as provided from the qemu project >> qemu for openmoko wiki.openmoko.org >> qemu for coreboot.org >> and probably others. >> >> If it would be possible t load modules like the (linux)kernel it would be >> possible to use one qemu version for all the projects. >> I don't know if this is possible? >> > > This has been discussed before and I believe the overall consensus was that > plugins are not desirable. > > With respect to the various forks of QEMU, I believe the real problem is > that historically, people have had a tough time getting changes into QEMU. > This is not just a matter of getting patches accepted, but also getting the > appropriate guidance about how to refactor things to take into account all > of the various architecture combinations that QEMU supports and some of the > longer term efforts. > > I hope this situation is improving. If people have feedback in how things In general I think the situation has improved alot. Personally I think the work that in particular Anthony (others too) is doing with reviewing and applying patches is just fantastic. > could be improved, I think everyone is eager to here it. Plugins are not > the solution though. Personnaly I would welcome some kind of plugin interface for some parts of QEMU but only if someone comes up wiht a an interface that does not hurt performace. I'd definitely have a use to plugin callbacks for every memory accesse in system-mode and I've noticed a reocurring request for hooks to trap syscalls while user-mode emulating. Best regards Edgar