qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005


From: Grzegorz Kulewski
Subject: Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005
Date: Thu, 17 Feb 2005 23:18:22 +0100 (CET)

Hi,

On Thu, 17 Feb 2005, Herbert Poetzl wrote:

On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote:
Hi,

On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
Following Fabrice decision to transform QEMU into a proprietary closed
solution

No, Fabrice did not transform QEMU into anything. He simply added another
optional module than can make QEMU faster and more bug-free. You can still
use QEMU without the accelerator and be perfectly happy with it. Also any
further development in area of IO, devices and so on will make both
versions better. KQEMU is only very small accelerator.

well, unfortunately together with the following mail ...

| From: Fabrice Bellard <address@hidden>
| To: address@hidden
| Date: Sat, 29 Jan 2005 22:48:24 +0100
|
| Hi,
|
| I plan to remove the 'qemu-fast' target in the next release of QEMU. It
| is too painful to maintain, difficult to port and it needs a patched
| guest OS to work correctly.
|
| This target is replaced by the standard QEMU with soft mmu support. The
| QEMU Kernel Acceleration Layer which will be unveiled very soon will
| give much more performance while working with unpatched guest OSes.
|
| Fabrice.

the future looks more like this:

- you want the same performance or better as before?
  then you have to use 'my' proprietary kernel module
  which isn't even open source (so that somebody
  could verify that it isn't that evil ...)

- of course, you can use the slow version and
  contribute to the development of the commercial?
  version ...

Well

1. qemu-fast is still there but disabled by default,
2. qemu-fast used patched kernel and was very limited and probably buggy,
3. you can use UML or plex86(?) for the same (== running Linux under Linux),
4. you can always write your own accelerator (its very small),
5. looking at the output of nm this .o file is probably harmless - it does not call anything from kernel but the functions in its interface in .c and .h files. I think this is needed for example because of 2.4 <-> 2.6 portability and proves good clean design. Of course theoreticaly this module can copy and steal some memory location but it is far from being trivial and it is probably nearly impossible to write this part of memory somewhere without calling anything... Besides Fabrice == spyware author??? :-) 6. contributing to userspace part means contributing to something free. Everybody could create some kind of accelerator even before Fabrice did and everybody can do it now... And everybody can sell his proprietary accelerator with the free userspace code (if some conditions are met).


proprietary kernel modules are a dangerous thing ...

I agree...


Grzegorz Kulewski





reply via email to

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