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

[Jan Kiszka]

Andreas Färber wrote:
> Am 31.05.2009 um 11:15 schrieb Jan Kiszka:
>> 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)

A certain level of experience (or drive to build it up) is required for
this. This will never be a "mechanical" porting job (for the same
reason, kqemu is doomed to die once things seriously start to fall apart
and there is still no one to dig deeper into it).

> 
> 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.

Kqemu is already GPLv2, so the picture would not really change. And
unless the license of the target OS does not exclude binding against
GPL'ed drivers, there is no problem to be expected.

> 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.

Like many others, I'm doing both, ie. not all of my open source work is
directly paid.

> 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.

As we are doing open source, we do have this discussion here and now, we
do consider options how to evolve qemu best (instead of just sticking
*forever* with legacy support that is no longer making progress and is
starting to cause troubles), and we do not just discontinue it like it
may happen with some commercial software.

Recall: Removing kqemu did not make into the repos, it did not even make
it on the agenda for 0.11. So there will like be at least another year
to look for alternatives on other platforms + the ability to use stable
0.11 even longer - at least as long as kqemu works.

> 
> 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?

As I tried to explain: All nice ideas also require someone to work on
them or to pay for this or to otherwise convincingly motivate people to
do this.

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

Should probably be fixed or even dropped (it suggests that on FreeBSD
kqemu == kvm).

Jan

signature.asc
Description: OpenPGP digital signature