Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity <avi@redhat.com>]

  On 09/05/2010 06:44 PM, Andreas Färber wrote:
> Am 05.09.2010 um 16:17 schrieb Avi Kivity:
>
>> On 09/05/2010 05:10 PM, Blue Swirl wrote:
>>> Easy to use GUI and integration to host system are important, but
>>> performance is also a big problem. QEMU/TCG can't compete with
>>> alternatives that use proprietary kernel modules. Someone should
>>> recreate kqemu by using KVM compatible interfaces.
>>
>> If someone is really willing to invest the effort to do that cleanly, 
>> I am willing to merge it into kvm.  That would allow reuse of the mmu 
>> and some other logic that got a lot of effort in kvm.
>
> I believe I already inquired about this when kqemu was dropped: KVM is 
> GPL'ed iiuc. May we use it as a kernel extension with proprietary Mac 
> OS X at all then? 

No idea.

> I thought there was some controversy on whether runtime-linking GPL 
> modules to a closed-source kernel constitutes a GPL violation or not. 
> (it would be news to me if Darwin/x86 was ever supported by kqemu)
> Having kqemu running as a userland service process (?) on Windows 
> seems unproblematic by comparison.

These things want to run in the kernel (or did you mean a kernel driver 
providing services to userland?)

> Don't know about the BSDs or how this would fit with OpenSolaris' 
> CDDL. On Haiku new kernel code would probably be preferred under 
> MIT/X11 License.
>
> In either case, I'm not aware of a clear documentation of what exactly 
> is required to implement on the kernel side to replace kqemu or to 
> provide a completely compatible implementation. It seems like a moving 
> target.

You can pick any recent snapshot and implement its interface.  We don't 
force to upgrade their kernel as we go along.

>> However, I doubt it is worth the effort, if anyone is interested in 
>> performance then they'd get a cpu that supports virtualization.
>>
>> That leaves non-Linux.
>
> This discussion was about non-Linux only. We can hardly call the Linux 
> build unmaintained! :)

Yeah - I though it diverged to whether we ship a bundled GUI or not - 
without that, performance doesn't really matter for non-Linux.

-- 
error compiling committee.c: too many arguments to function