[Qemu-devel] Re: KQEMU code organization

[Jan Kiszka <jan.kiszka@siemens.com>]

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