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

[Fabrice Bellard <fabrice@bellard.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.