Re: [Qemu-devel] Killing KQEMU

[Paul Brook]

> And to any devs who are eager to rid Qemu of KQemu - first, thanks for Qemu
> :-) ... but also, why are you eager to rid Qemu of KQemu?  (this is not a
> rhetorical question - very sincere question.  I'm looking to learn here...)
> I understand that KQemu is perhaps sub-optimal in some or many ways, and/or
> abandoned.  Does keeping the KQemu-supporting bits in Qemu cause some
> hindrance in developing other features?

osdep.c:/* FIXME: This file should be target independent. However it has kqemu
vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)

If you want kqemu to continue existing, you need to find someone to actively 
maintain it. IMO at bare minimum all the above need to go away. AFAIK there's 
not currently anyone has the time/inclination to do this, and from most 
accounts kqemu doesn't really work very reliably at the best of times.

Or let me put it another way: At some point I'll get fed up of the limitations 
that kqemu currently imposes, and deliberately break it. If it remains broken 
then it will be removed. You get to decide whether you want to fix kqemu, 
start again from scratch (probably enhancing KVM), or keep using old versions 
of qemu.

As I've said before, if you're serious about maintaining kqemu you probably 
need to get it integrated into mainstream kernels. Without this a large 
portion of the relevant communities simply aren't going to care.

Paul