From: Paul Brook <paul@codesourcery.com>
To: Chris Frey <cdfrey@foursquare.net>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Killing KQEMU
Date: Tue, 2 Jun 2009 21:30:42 +0100 [thread overview]
Message-ID: <200906022130.42639.paul@codesourcery.com> (raw)
In-Reply-To: <20090602200918.GA27850@foursquare.net>
>> 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.
next prev parent reply other threads:[~2009-06-02 20:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 3:52 [Qemu-devel] Killing KQEMU Chris Frey
2009-06-02 4:18 ` Avi Kivity
2009-06-02 6:28 ` Avi Kivity
2009-06-02 19:25 ` [Qemu-devel] " Chris Frey
2009-06-02 4:45 ` [Qemu-devel] " Rick Vernam
2009-06-02 12:54 ` Paul Brook
2009-06-02 20:09 ` [Qemu-devel] " Chris Frey
2009-06-02 20:24 ` Avi Kivity
2009-06-03 21:50 ` [Qemu-devel] " Chris Frey
2009-06-04 6:30 ` [Qemu-devel] " Avi Kivity
2009-06-02 20:30 ` Paul Brook [this message]
2009-06-03 21:34 ` Chris Frey
2009-06-03 21:46 ` Rick Vernam
2009-06-06 11:01 ` Andreas Färber
2009-06-06 11:27 ` Paul Brook
2009-06-06 13:50 ` Andreas Färber
2009-06-06 15:24 ` Gleb Natapov
2009-06-06 16:03 ` Avi Kivity
2009-06-02 20:35 ` Gerd Hoffmann
2009-06-02 20:47 ` Stuart Brady
2009-06-03 21:21 ` [Qemu-devel] " Chris Frey
2009-06-04 0:22 ` Paul Brook
2009-06-02 6:25 ` [Qemu-devel] " Gleb Natapov
2009-06-02 9:26 ` Anton D Kachalov
2009-06-02 19:47 ` [Qemu-devel] " Chris Frey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906022130.42639.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=cdfrey@foursquare.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).