Re: [Qemu-devel] The QEMU Accelerator Module

[Grzegorz Kulewski]

Hi all,

On Fri, 11 Feb 2005, Karel Gardas wrote:
> On Thu, 10 Feb 2005, Tom Marble wrote:
> > Fabrice Bellard wrote:
> > > KQEMU is _not_ open source as the rest of QEMU. It is a proprietary
> > > kernel module (read the LICENSE file) and will stay so until a gentle
> > > company decides to subsidy the QEMU project.
> >
> > I'd like to make an appeal that KQEMU be licensed under the GPL.

I hope it will happen soon.


> > I'm not going to try to roll out a general FOSS position statement, but
> > speak from a more practical level:
> > - This technology is extremely important for faciliting automated
> >   testing of the full (open) stack (including BIOS, ACPI, storage,
> >   graphics, OS, swsusp).  And that testing is vital to the continuing quality
> >   and vibrance of the entire stack.

Ok, but it does not stop you from testing. Look at the binary-only part 
size and its interface in .c and .h files. If I understand it correclty 
Fabrice (as usual) done things in extremely right way. The proprietary 
module is _only_ the accelerator. All emulation is done in userspace. Both 
with and without kernel module you get the same qemu (modulo 
userspace-only CPU implementation bugs on unpriviledged instructions if 
there are any left). Only some virtualization is done in kernel. So every 
IO device is exactly the same in both versions of qemu.


> > - non-GPL kernel modules will taint the kernel and completely
> >   change the trajectory of the technology (it's support, innovation,
> >   evolution, etc.)

I think that you are not 100% right. I think that adding non-GPL module to 
the kernel is the (nearly only) problem of this aproach because you will 
loss support from LKML and Linux Community. You will need to reproduce all 
problems on vanilla kernel. (It is not clear if even with GPL licence 
kernel developers will want to support kqemu enabled kernels but the 
module is so small and probably so unintrusive that maybe in could be 
merged into -mm very fast or at least be considered as not-the-cause of 
your issues.)

But saying that it will "change the trajectory of the technology" is I 
think a little too much. Ok, you will not be able to hack on the module 
itself but (if I understand it correctly) Fabrice did everything to place 
as little as possible amount of code in it. After several trivial bugfixes 
of its child age it will probably be left untouched. So you can change 
nearly everything in qemu if you like. It is not 100% freedom but say 
99.999%... :-)

Besides, maybe I am not right, but I do not think that more than 1 or 2 
developers of qemu will want to hack on its kernel module. I do not even 
think it will be good. It should remain as small and simple as possible.


> > Is KQEMU valuable?  Absolutely!  Could it be proprietary?  Of course
> > (vis VMware).

There is _big_ difference. In VMware you can change nothing. Not even add 
new device.


> > In this strange calculus of open source, as counterintuitive
> > as it seems, I'm convinced that it can be even *more* valuable as
> > GPL technology (to the community) and more valuable to Fabrice
> > personally.  While there may be many shades of 'open' (e.g. blender)
> > I'm sure that that community would be much more productive
> > with a GPL license and consequently would provide much more
> > enthusiastic support of whatever Fabrice needs.

But I do not see any milionaire on this list? I am wrong?


> > I'm sure everyone would be willing to help Googlebomb and /.
> > Qemu, right?  (Or better yet, help make KQEMU *even better*
> > through many eyes so that it can really reach a new level of success).
>
> I think that you makes your appeal on the wrong side. Please read
> Fabrice's note above. You should rather contact your Linux distribution
> vendor and try to convience it to sponsor kqemu development and switch to
> GPL. You can also contact some other linux friendly companies like IBM/HP
> to do the same.

Exactly. Question if Fabrice will want gigant to support qemu or rather 
several (possibly) smaller companies? (IIRC author of plex86 was fired 
from Mandrake because of some reduction so maybe several companies would 
be better?)


> I'm afraid you are not right with your preassure to how much this
> technology is important. No, it is not important for testing of
> BIOS/ACPI/kernel etc. It's just very important for end user because of
> possible (as I hope) performance benefit.

And BIOS and ACPI and other IO and even priviledged instructions are done 
in userspace in open source code (or I am completly wrong...)

And if you are really briliant programmer you can write that 36k of code 
yourself. The only thing that stops me from (trying) doing so is that 
it would be not fair to Fabrice. Maybe I am too self-confident but it 
really should not be that hard to do if you know kernel programming a 
little (and assembler of course) or have somebody to anwser your 
questions. This is maybe good exercise to everybody: write your own and 
sent it to Fabrice... ;-)  Of course any form of reverse engineering is 
considered cheating and does not produce the main good: learning how to 
make exciting things in kernelspace.


> Once again I would like to thank Fabrice for making kqemu enough free that
> Qemu user community can benefit from it and provide some bugreports, which
> hopefully will be also benefit to kqemu itself. I hope that members of
> Qemu community will understand this Fabrice's step and will support him in
> finding appropriate company willing to pay for (K)Qemu's development.

Me too. :-)


Thanks Fabrice.

Grzegorz Kulewski