From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1OeB-0001u3-3S for qemu-devel@nongnu.org; Wed, 28 May 2008 12:37:07 -0400 Received: from [199.232.76.173] (port=59593 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1Oe9-0001tv-Qh for qemu-devel@nongnu.org; Wed, 28 May 2008 12:37:05 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]:53891) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1Oe9-00062M-Gm for qemu-devel@nongnu.org; Wed, 28 May 2008 12:37:05 -0400 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id D796C3316B for ; Wed, 28 May 2008 18:37:02 +0200 (CEST) Message-ID: <483D8A2E.5070907@bellard.org> Date: Wed, 28 May 2008 18:37:02 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KQEMU code organization References: <483C3D55.2000508@siemens.com> <483C8705.307@bellard.org> <483D81FA.5070202@siemens.com> In-Reply-To: <483D81FA.5070202@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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: > 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. I may change the monitor blob format to ELF to allow relocation, but the idea stays the same, and I don't think you can do it another way... > 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. Right. This is what I do. Fabrice.