From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K17P5-0000fN-TT for qemu-devel@nongnu.org; Tue, 27 May 2008 18:12:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K17P3-0000eO-MM for qemu-devel@nongnu.org; Tue, 27 May 2008 18:12:22 -0400 Received: from [199.232.76.173] (port=59036 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K17P3-0000eJ-Ep for qemu-devel@nongnu.org; Tue, 27 May 2008 18:12:21 -0400 Received: from relay3-v.mail.gandi.net ([217.70.178.77]:36424) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K17P3-0003Pk-3Y for qemu-devel@nongnu.org; Tue, 27 May 2008 18:12:21 -0400 Received: from localhost (mfilter5-v.gandi.net [217.70.178.39]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id 1238FBA18 for ; Wed, 28 May 2008 00:12:20 +0200 (CEST) Received: from relay3-v.mail.gandi.net ([217.70.178.77]) by localhost (mfilter5-v.gandi.net [217.70.178.39]) (amavisd-new, port 10024) with ESMTP id rPAKTDjyaFCB for ; Wed, 28 May 2008 00:12:18 +0200 (CEST) Received: from [84.102.211.103] (103.211.102-84.rev.gaoland.net [84.102.211.103]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id 40E88BA16 for ; Wed, 28 May 2008 00:12:18 +0200 (CEST) Message-ID: <483C8705.307@bellard.org> Date: Wed, 28 May 2008 00:11:17 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] KQEMU code organization References: <483C3D55.2000508@siemens.com> In-Reply-To: <483C3D55.2000508@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit 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 Jan Kiszka wrote: > Hi, > > is there a technical reason why the kqemu kernel module is built out of > a binary blob (monitor-image.bin->monitor-image.h)? Does this simply > date back to the time when wrapper and core were distributed under > different licenses? This is a technical reason: the "blob" is run in an address space different from the host kernel. Fabrice.