[Qemu-devel] Re: [PATCH] remove pieces of source code

[Glauber Costa <glommer@redhat.com>]

On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote:
> Anthony Liguori wrote:
> > Glauber Costa wrote:
> >> Have you ever seen a girl so beautiful that you, geeky,
> >> think: "I'll never stand a chance"?
> >>
> >> But sometimes, you decide to make your move anyway. There's
> >> always the chance that in that very day she'll be specially
> >> in good mood, and you'll get what you want.
> >>
> >> With the exception of the fact that qemu is not a girl,
> >> that's more or less what I'm trying to do here: Hopefully,
> >> nobody will notice what I'm trying to do, and will commmit it.
> >> Later, when realizing, it will be too late. Victory will be mine.
> >>
> >> Or maybe people will even agree. For that, I'll try briefly
> >> to arguee my point, without disclosing to much, avoiding
> >> jeopardizing the strategy I explained above:
> >>
> >>   This patch removes a piece of code that is unmaintaned,
> >>   that does not receive an update for years,
> >>   that get bug reports on the list that nobody fixes, because
> >>   nobody really understands,
> >>   that places some artificial constraints on other subsystems
> >>
> >> Signed-off-by: Glauber Costa <glommer@redhat.com
> > 
> > Let's actually build a proper case instead of closing our eyes and
> > hitting enter.  Here are the downsides of kqemu I know of:
> > 
> >  o Since it's enabled by default, it forces the default build to support
> > < 4GB of guest memory
> 
> Making -no-kqemu the default appears as a reasonable first step then -
> to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
> collect complains like: "What the heck happened to kqemu?"
We have at least one _stable_ release at this point that includes kqemu.
So why not just remove it for the next one?

> 
> >  o There is no alternative for non-Linux users and folks with non-VT/SVM
> > hardware
> 
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon. The non-Linux issue will likely persist - unless someone feels so
> much pain to write some KVM for those platforms. But as long as there is
> a kqemu version that builds and works for them, I think we should keep
> QEMU's support. But it should no longer be a first-class citizen: off by
> default, factored out into more hooks, maybe even de-optimized where it
> blocks development or increases the maintenance effort of QEMU.

Any change we make to decrease its citizenship status will likely break it
very fast. Reality is noone here really understands it.