From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1hzM-0006v6-Pa for qemu-devel@nongnu.org; Thu, 29 May 2008 09:16:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1hzL-0006u7-2X for qemu-devel@nongnu.org; Thu, 29 May 2008 09:16:15 -0400 Received: from [199.232.76.173] (port=59072 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1hzK-0006u1-Rc for qemu-devel@nongnu.org; Thu, 29 May 2008 09:16:14 -0400 Received: from gecko.sbs.de ([194.138.37.40]:15068) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1hzK-0007I2-Ez for qemu-devel@nongnu.org; Thu, 29 May 2008 09:16:14 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4TDGBdv008079 for ; Thu, 29 May 2008 15:16:11 +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 m4TDGB5R022723 for ; Thu, 29 May 2008 15:16:11 +0200 Message-ID: <483EAC9B.6010701@siemens.com> Date: Thu, 29 May 2008 15:16:11 +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> <483D8E9A.40509@siemens.com> <483EA1AD.1010901@bellard.org> In-Reply-To: <483EA1AD.1010901@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: >>>> 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. > > This is purely cosmetic and I am generally against such changes. See, the current code structure is not optimal /wrt understandability. KQEMU is a complex topic, no question. But this doesn't mean the structuring need to be that complex as well. Everything that helps to make things straighter, quicker to overview, can also help third parties to analyze KQEMU, debug potential issues, or even enhance its feature set. >> 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. > > For true kernel components I agree it is useful. > > Regarding the kqemu evolution, I am doing small API changes to make it > more independent from the QEMU internal data structures and to allow > usage from a 32 bit user QEMU application with a 64 bit host. There is > also another small change I did some time ago but never published to > allow paravirtualization of the Linux kernel. OK, thanks for the info. Just leaves me with the open questions about the planned license(s) and how/where KQEMU is going to be maintained in the future. I would really like to see it being driven as actively (and broadly) as the QEMU core - specifically as long as HW-virtualization is still not the rule on existing platforms :-/. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux