qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: Killing KQEMU


From: Paul Brook
Subject: [Qemu-devel] Re: Killing KQEMU
Date: Tue, 2 Jun 2009 21:30:42 +0100
User-agent: KMail/1.11.2 (Linux/2.6.29-2-amd64; KDE/4.2.2; x86_64; ; )

>> 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)
>
>These are fairly small annoyances, no?  I'm assuming they are, since they
>exist at all, considering the frustration evident in:

They're horrid hacks that I only reluctantly created in the first place. 
Limiting guest physical memory to 4G is a fairly serous issue. Requiring the 
user specify how much ram they require upfront will not be acceptable once we 
have machine config files.

>> 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.
>
>I would hope that anyone who deliberately breaks kqemu support would be
>kind enough to post that fact to the mailing list

Sure, but this is actually part of my point.  If noone cares enough to 
track+test the development branch, then it just proves how little anyone 
actually cares about kqemu.

> > 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.
>
> According to other threads on this list, it would appear that getting
> KQEMU into the kernel is often thought of as impossible, or "would never
> happen."

In its current form that's probably true. It may effectively require a 
complete rewrite.

OTOH kqemu has some fairly serious bugs, and may need a complete rewrite to 
fix those bugs.  IMHO current kqemu is effectively unsupportable[1] for any 
serious use, which is one of the reasons I'm not concerned about it going away 
in the near future.

Paul

[1] Unsupportable == I'm not letting it anywhere near my production systems. 
When it breaks you keep both pieces, and it's unlikely anyone knows how to 
glue them back together again.




reply via email to

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