From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1Owm-0001zt-BK for qemu-devel@nongnu.org; Wed, 28 May 2008 12:56:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1Owk-0001z0-Ax for qemu-devel@nongnu.org; Wed, 28 May 2008 12:56:19 -0400 Received: from [199.232.76.173] (port=33817 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1Owk-0001yx-7o for qemu-devel@nongnu.org; Wed, 28 May 2008 12:56:18 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:16160) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1Owj-0003cS-Ko for qemu-devel@nongnu.org; Wed, 28 May 2008 12:56:18 -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 m4SGtsaa024072 for ; Wed, 28 May 2008 18:55:54 +0200 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail1.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4SGtsP3019227 for ; Wed, 28 May 2008 18:55:54 +0200 Message-ID: <483D8E9A.40509@siemens.com> Date: Wed, 28 May 2008 18:55:54 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <483C3D55.2000508@siemens.com> <483C8705.307@bellard.org> <483D81FA.5070202@siemens.com> <483D8A2E.5070907@bellard.org> In-Reply-To: <483D8A2E.5070907@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: >> 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... I agree (from my current knowledge of the problem) that the monitor remains "foreign" code to the kernel module. But at least the repackaging into a c-structure should be unnecessary. The offset generation can be skipped if the assembly files are converted into inline assembly. Might be tricky in some cases, but I see no show-stopper yet. The give it a tiny start, I will look if I can unify the build process for all "true" kernel components. That is what currently breaks the debugability of the driver frame (up to kernel2monitor), and which also causes a kbuild warning. Likely harmless ATM, but it is fragile on long-term. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux