[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH] remove pieces of source code
[Qemu-devel] Re: [PATCH] remove pieces of source code
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
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
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!
Re: [Qemu-devel] [PATCH] remove pieces of source code, Glauber Costa, 2009/05/29
[Qemu-devel] Re: [PATCH] remove pieces of source code, Jan Kiszka, 2009/05/31
- Re: [Qemu-devel] [PATCH] remove pieces of source code, Gerd Hoffmann, 2009/05/29
- [Qemu-devel] Re: [PATCH] remove pieces of source code, Consul, 2009/05/29
- Re: [Qemu-devel] Re: [PATCH] remove pieces of source code, Glauber Costa, 2009/05/29
- Re: [Qemu-devel] Re: [PATCH] remove pieces of source code, Andreas Färber, 2009/05/30
- [Qemu-devel] Re: [PATCH] remove pieces of source code, Jan Kiszka, 2009/05/31
- [Qemu-devel] Re: [PATCH] remove pieces of source code,
Andreas Färber <=
- Re: [Qemu-devel] Re: [PATCH] remove pieces of source code, Avi Kivity, 2009/05/31
- Re: [Qemu-devel] Re: [PATCH] remove pieces of source code, M. Warner Losh, 2009/05/31