Re: [Qemu-devel] Qemu - where will it go?

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

that's an interesting topic you bring up there :D

It looks like there are many different groups which all have quite
different uses of qemu on their mind... Jürgen, you think about a
_really_ stable "hardware" platform; other people think about a honeypot
framework; even other people want to have lots of different system
architectures for software development and testing; I myself just want a
way to have a Windows available on my Linux PC, for gaming and running
Windows apps. Not to mention the various toy-like uses, like the Linux
screensaver. And if I got that correctly, one of the original uses of
qemu was to run wine on PPC - ironically, this is probably not such an
issue now, with Apple switching to x86 :)

So, to me it seems like the many different uses of qemu indeed need a
very different qemu each; and though I'm not a qemu developer at all
(and hence can't "demand" any specific direction of development), I'd be
glad if qemu wouldn't just go into one direction.
Maybe it is indeed about time to think about the "main uses" that qemu
should satisfy. For me, that would be the "Windows-sandbox on my Desktop
Linux": with a nice GUI, an assistant to help with the creation of a new
image, with some guest-side tools for more convenience, with not too
slow graphics, and without big ties to the host system.

Jürgen has stated his desired functionality already. What other "main
uses" are there? (Asked in the hope of further sparking the discussion ;)


To summarize what in my opinion are the most important advantages of qemu:

Over eg. VMware and VPC, it has these advantages:
- -small
- -easy to install; VMware requires a kernel module from the start, and
requires running of an installation script (*yuck* and that in times of
RPM and APT).
- -Open Source (= possibility to meddle with it by myself; and no
dependency on a self-centered, not-to-be-trusted company)

Over Wine, qemu has the advantage that it runs guest apps without any
worrying whether the emulation is "complete enough" for that app.
Over Xen and UML, it has the advantage that it runs Windows, even
without special hardware.
Over Bochs, it has the advantage that qemu runs fast yet still reliable
enough.

What other product did I miss that might compete with qemu? What
advantages of qemu did I miss?

Thanks in advance for your replies,
Oliver


Juergen Pfennig schrieb:
> Hello dear readers,
> 
> as I found out qemu is quite stable and has acceptable performance. Using it 
> you
> could freeze legacy applications using a legacy OS like win 2003 or win XP. I 
> am
> talking of periods from 5 to 20 years! In a commercial environment it happens 
> frequently that you would like to access old data but cannot do so because the
> hardware is gone or the old software does not work with the current OS.
> 
> Commercial vm solutions cannot really do that - as they are not open source 
> you
> only move the dependecies from hardware to a software vendor. Both usually
> become unavailable over time. Hardware vitualization (xen, vanderpool) is also
> not an ideal long-term solution, you become again hard-ware depending...
> 
> This is what makes qemu so interesting for industry and business.
> 
> But a lot of work would have to be done. The next steps of development would
> probably include:
> 
> - run qemu as a service (on Windows or on Linux using xinetd)
> - make rdp (Win Terminal Server) work when qemu started via
>   xinetd
> - improve disk image format, better snapshot handling
> - make a plugin architecture for the host side device implementation
> - allow 'remote' host side devices (sound, usb, serial ...)
> - define a protocol to use qemu over a network (should multiplex
>   video, sound, usb, serial and so on).
> 
> So you see: in a commercial  and or industrial application one would like to 
> run 
> the qemus on a server. At least the MS remote desktop protocol should work
> well. A qemu specific client would be nicer. 
> 
> Please do not try to make the current qemu program a better GUI application -
> do it the other way: move SDL out of qemu and write an extra client app!
> 
> I did not find any information concerning the plans that the maintainers of
> qemu have.
> 
> - currently it is simple and easy to understand. It has supringly few lines
>   of code.
> - the concept would allow for better performance (dynamic code generation
>   could use optimization to eliminate inter module function calls, see some
>   of the java jit propaganda).
> - currently the code translation cache is a problem for old-style windows
>   apps. Word and friends run slowly as the cache runs full and gets 
>   rebuilt too often. The current implementation may lead to degeneration,
>   e.g. a very low cache hit ratio.
> - obviously a generational code translation cache should be used, e.g.
>   frequently executed code would not be lost but would be promoted to
>   the next generation cache. See the .net gc propaganda.
> - Finally one could take some ReactOS drivers to get better perfor-
>   mace by not going through hw emulation but by making the ReatOS
>   drivers stubs that can call native implementations on the host side.
> 
> Unfortunately implementing the things that I was talking about would blow
> up the size of the code base dramatically. Qemu would never again be
> small, pretty and easy to understand. Where do you want to go?
> 
> Yours Jürgen
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDyU7yTFOM6DcNJ6cRAjg2AJ41ExETauoBTmvl+r55OZO4P6kviwCgrVDj
TO8WUc4eRT1El0jFjI9aYvc=
=rYlu
-----END PGP SIGNATURE-----