Re: [Qemu-devel] Just a thought (high level API)

[Nathaniel McCallum]

On Wed, 2005-02-09 at 19:02 -0500, Jim C. Brown wrote:
>On Wed, Feb 09, 2005 at 10:09:04AM -0500, Nathaniel McCallum wrote:
>> I know a lot of people are wanting to build qemu frontends and embedding
>> the sdl window has been a frustration to several.
>
>A file that allowed one to use Xliib instead of SDL was release a while back
>(you just replaced the real sdl.c with this file and recompiled) but it was
>never added to qemu directly.
>
>One reason is because there was no clean way to add it, but it also seems that
>Fabrice seems unwilling to add X support directly into qemu. (He has never
>explained this, he simply said that he'd accept code for Win32, GTK, and MacOS
>graphics support).
>
>The first part can be dealt with by creating a "GUI" api for qemu, with SDL
>as the default driver. That would make it easy to stick in other front ends.

The point of the api that I proposed is to easily allow video
"sinks" (ie. SDL, GTK, etc) that don't have to belong into the tree. The
idea is to abstract the actual emulation functions away from the user
interface (right now these two are not really abstracted at all.  there
is both emulation code and user interface code in vl.c).  I'm suggesting
to take all the emulation code, stick it behind some kind of api
(whether mine or not) and let user interfaces (including the current
qemu console based UI) use that api.  If we do this, people can develop
GTK, Xlib, Win32, QT, SDL or any other user interface *external* of the
qemu tree.  This lets people who want to work on gui stuff (me) work on
gui stuff without having to worry about emulation stuff.

To summarize, all emulation specific stuff should be in the library.
Anything that interacts with users should make calls to that library.


>The above idea (creating a GUI api) would be enough for this, unless you want
>to add extra (such as QeWS does). We would probably want more than one API
>for qemu overall, it already has one for sound support.


My point is to abstract some of this stuff.  Check out the model
attached.

No matter what video card we emulate, we are still going to need to send
raw raster video data to whatever video sink we use (SDL, GTK, W32,
etc).  Thus, we separate the video card emulation and then send the raw
data to a plugin that knows how to handle that kind of data.  Same with
audio data.  Whatever API you want internally for various different
drivers is fine.  But its just that, an *internal* api.  For actual
front ends (and embedding purposes... emagine coding on the linux kernel
in emacs and hitting a button to compile your changes and test them in a
virtual machine!) we need a high level *external* api.


>Sidenote: it is possible to use only the GUI api for frontends such as QeWS,
>they would just need a custom driver that talks to the frontend (and thus the
>frontend can directly handle all the graphics itself).

The point is to not have to have special drivers (which requires GUI
programmers to think about emulation stuff), but to have an external API
where they only have to think about displaying raw data using a clean
documented API.

>
>>   3. Allow for storable virtual machine profiles which could be shared
>> across all front ends (ie. a virtual machine profile could be used in
>> QemuX, a Win32 frontend, a GTK frontend, etc...)
>> 
>
>I don't understand what you mean by "virtual machine profile".

Ok.  You create a virtual machine.  Lets call it "Windows 2000." Every
time you want to launch "Windows 2000" you type: "qemu
-hda /home/me/w2k.img -cdrom /dev/hdc -m 256 -boot c -user-net -n 3".  A
Virtual Machine Profile describes a virtual machine and stores it in a
file for easy recall.  So instead of typing the above, you have a file
that contains (ini-style just for the example):
[Virtual Machine]
hda=/home/me/w2k.img
hda_type=HDD
hdc=/dev/hdc
hdc_type=CDROM
memory=256
default_boot=hda
net_type=USER
nic[0]=00:00:00:00:00:00
nic[1]=00:00:00:00:00:01
nic[2]=00:00:00:00:00:02

That file is saved as w2k.vmp.  To start this virtual machine (instead
of typing the options above) you would do: "qemu
--profile /home/me/w2k.vmp"  While the benefit doesn't look that big
from a command line perspective, from a Front End perspective, it is
huge.  You can manage huge lists of virtual machines and it is
compatible over various Front Ends.  Thus if you create a virtual
machine in the GTK front end of QEMU you can load that same virtual
machine (without any changes) in the KDE/Mac/W32/E17/etc... front end.
This makes for a great user experience.

Nathaniel

libqemu.png
Description: PNG image