Re: [Qemu-devel] Killing KQEMU

[Rick Vernam]

On Monday 01 June 2009 10:52:17 pm Chris Frey wrote:
> Hi,
>
> I feel that I should post here, for the simple reason that most QEMU
> users likely don't read this list, and have no idea that developers are
> striving to kill off a valued feature.
>
> This is a very valuable feature to me, as one of those users, and I find
> it sad to read the eagerness some have at getting rid of it. Not everyone
> has access to the most modern hardware. And not all hardware is worth
> throwing out just because it doesn't have a CPU capable of virtualization.

First, I am in the same class as you: no hardware extensions for virtualization, and I'm not going to buy new hardware for that alone.
I haven't seen anything that I consider eagerness to get rid of KQemu, perhaps you've read something off list or I've missed something on list? I am curious.

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?

Anyway, thanks for all your work. In case there really is any eagerness to kill off KQemu, I'm just dropping a friendly reminder that there are some grateful folks out here who do actually use KQemu :-)

>
> I read excuses such as "it's not documented" and "nobody understands it"
> and "there's no maintainer", but in a project such as QEMU, that is nearly
> 500,000 lines of code, the KQEMU kernel module clocks in, for linux,
> at a whopping 674 lines.
>
> I find it hard to believe that these 674 lines of code are too much for
> the substantial braintrust available on this list.
>
> Wasn't KQEMU written in the first place to be small, auditable, and
> secure? What has changed that it is now such a burden?
>
> Thanks,
> - Chris