[Top][All Lists]

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

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

From: Andreas Färber
Subject: [Qemu-devel] Re: [PATCH] remove pieces of source code
Date: Sun, 31 May 2009 15:08:35 +0200

Am 31.05.2009 um 11:15 schrieb Jan Kiszka:

Andreas Färber wrote:

KVM is no alternative either for us because nobody really maintains
documentation of what interface and functionality we'd have to implement
on Solaris, Windows, Mac OS X etc. where no KVM is available today.

I'd expect some documentation here:
http://www.linux-kvm.org/page/Documents -- but no luck. No "Porting KVM
For Dummies". ;(

There was and likely will never be any documentation for kqemu either.

And I'm not complaining about kqemu. No one has suggested me to start new ports of kqemu.

But having worked on both, I can say that kvm is by an order of
magnitude easier to understand from its sources than kqemu.

Sorry, but if you are really interested in such a port, having to dig
through source code and ask questions to the community if something
remains unclear should not be the actual problem.

It is. My using the kqemu accelerator neither makes me an expert on x86 architecture nor on any sort of kernel modules. (Just like some understanding of TCG and certain other instruction sets doesn't make me too knowledgeable about IRQ, DMA, MMU, TLB and all the other TLAs)

The porting issues start with very basic considerations: IIUC the relevant part of KVM porting-wise is the kernel side (assuming that sufficient userspace code has arrived in upstream QEMU already), which by nature of Linux and according to the FAQ is GPL'ed. Meaning that if I attempted to port KVM to a new platform, the kernel module, Kernel Extension, daemon, Service, driver or whatever form of implementation may be needed on the target OS would be required to be GPL'ed as well. Can I create a GPL'ed Kernel Extension for Mac OS X? Questionable, since it would probably end up in the same address space as proprietary/non-GPL code. Similar potential issues with CDDL'ed (Open)Solaris kernel, BSD kernels, MIT/X11'ed Haiku kernel and fully closed-source Windows. So, to be on the safe side, I can't start implementing KVM by reading the KVM source code but would need documentation of the interface that needs to be implemented (cf. virtio drivers). If KVM wants to be the one standardized interface instead of one of three implementations then it needs formalization. There are contradicting answers on whether non-GPL code may legally dynamically load GPL code, making code and inline comments not necessarily a sufficient replacement for proper documentation. Especially if it's not my personal wish, but KVM developers trying to force people to port their software in order to make their life easier.

Arguing about Open Source, you are forgetting that not everyone gets paid for their Open Source contributions to QEMU. If you work on KVM/ QEMU for a living and have the time to work on large'ish porting or refactoring projects, that's one facet of Open Source only. Many other people aren't selling but merely using QEMU, be it as a tool for (Open Source) application or operating system development or for research, because they favor it as a FOSS solution, contributing bugfixes and to ongoing platform support. These are often not the same people building QEMU on a per-commit basis, testing every apparently unrelated patch before it gets committed and breaks things for them, and are thus hit the most when some member of the now highly active KVM community decides to shuffle features around or to drop something in some upcoming release for valid reasons. Are they really "bad" community members? Should they better get lost, let you do your KVM work and go buy closed-source VMware instead? Or let partially open source VirtualBox freeze their system and ruin their Superdrive? I don't think so. Having flourishing KVM code inside QEMU is totally fine, but pointing the pistol at others, asking to port KVM to a new platform with a fixed timeframe and without documentation, even if KVM developers happen to dislike kqemu hooks in the sources and QEMU maintainers - being on Linux mainly - have turned to KVM, is not okay. The problem is not unwillingness, but rather time, information, skills, communicativeness and politeness. It makes a major difference if someone steps up and posts on qemu-devel, "hey, we'd like to replace kqemu with KVM, let's talk about how and when we can make this happen", rather than submitting a patch rendering the kqemu kernel module unusable, leaving the majority of its current users standing in the rain without replacement accelerator. That's got little to do with the spirit of Open Source.

I have a dream of something like the Open Group specification, which describes a virtualization standard in terms of required C types, preprocessor defines, functions, valid parameters, expected return values etc. It would allow multiple source-compatible but differing implementations and would in theory even allow to consolidate the current virtualization island solutions into sane, interoperable solutions. Is this too far from KVM reality?


P.S. The "KVM on BSD" page (http://www.linux-kvm.org/page/BSD) does in fact instruct people to use kqemu!

reply via email to

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