From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1hGJ-0006FW-MR for qemu-devel@nongnu.org; Thu, 29 May 2008 08:29:43 -0400 Received: from [199.232.76.173] (port=58029 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1hGJ-0006F2-3g for qemu-devel@nongnu.org; Thu, 29 May 2008 08:29:43 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]:34981) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1hGI-0001li-B5 for qemu-devel@nongnu.org; Thu, 29 May 2008 08:29:42 -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 A15CA33171 for ; Thu, 29 May 2008 14:29:38 +0200 (CEST) Message-ID: <483EA1AD.1010901@bellard.org> Date: Thu, 29 May 2008 14:29:33 +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> <483D8A2E.5070907@bellard.org> <483D8E9A.40509@siemens.com> In-Reply-To: <483D8E9A.40509@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: >>> 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. > 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. Fabrice.