[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KQEMU code organization

From: Fabrice Bellard
Subject: Re: [Qemu-devel] Re: KQEMU code organization
Date: Thu, 29 May 2008 14:29:33 +0200
User-agent: Thunderbird (X11/20070727)

Jan Kiszka wrote:
Fabrice Bellard wrote:
Jan Kiszka wrote:
Fabrice Bellard wrote:
Jan Kiszka wrote:

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]