From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1O6P-0005IM-D9 for qemu-devel@nongnu.org; Wed, 28 May 2008 12:02:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1O6L-0005Hd-By for qemu-devel@nongnu.org; Wed, 28 May 2008 12:02:12 -0400 Received: from [199.232.76.173] (port=44816 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1O6K-0005HW-Qg for qemu-devel@nongnu.org; Wed, 28 May 2008 12:02:09 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:23613) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1O6J-000086-P6 for qemu-devel@nongnu.org; Wed, 28 May 2008 12:02:08 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4SG22mD007032 for ; Wed, 28 May 2008 18:02:02 +0200 Received: from [139.25.109.167] (mchn012c.ww002.siemens.net [139.25.109.167] (may be forged)) by mail1.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4SG22BF028405 for ; Wed, 28 May 2008 18:02:02 +0200 Message-ID: <483D81FA.5070202@siemens.com> Date: Wed, 28 May 2008 18:02:02 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <483C3D55.2000508@siemens.com> <483C8705.307@bellard.org> In-Reply-To: <483C8705.307@bellard.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KQEMU code organization 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 Fabrice Bellard wrote: > 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. Well, easy to claim, I know, but I don't think this is a hard reason. However, as overcoming genmon and genoffset may require quite some refactoring, I'm not sure if it's worth it. For debugging purposes I meanwhile created my own build system anyway. gdb fortunately accepts an monitor-image.out built with -g so that source level debugging of the monitor is possible as well. /me now needs to understand how this thing works... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux