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

[Nathaniel McCallum <npmccallum@gentoo.org>]

On Wed, 2005-02-09 at 21:34 -0500, Jim C. Brown wrote:
> After thinking about it for a while, your approach is better. I then thought
> about taking it a step farther, and we could use multiple processes. The qemu
> exectuable would hold the main emulator engine, but it would send graphical
> output via a well documented protocol to a front-end process, and console
> output to a process (probably the same one but concievably a different one)
> via another protocol.

Interesting... though this would introduce a level of latency,
particularly troublesome when we are using 100% CPU for emulation.  We
then also have to deal with the IPC issue: UNIX/Linux/Mac can use dbus
or a unix socket, Windows can't use either of these.

While multiple processes would certainly be more stable, is it worth the
complexity it introduces?  A well planned out API might give us just as
much flexibility with higher performance and portability.

One advantage of the protocol/ipc method would be that you get free
bindings to any language (ie. any language can use the protocol).
However, the main languages that would use the API would be C (console
and gtk/gnome), C++ (w32 and qt/kde) and Obj-C (Mac) which can all use
the C API without any bindings, so its not a huge advantage unless
someone wants to embed qemu into something done in another language.
The API wouldn't be that big though, so bindings wouldn't be all that
problematic.

I'm open to the protcol/multiple processes approach if we can do it
with:
   1. low latency
   2. portability
   3. simplicity

> In other words, a config file?
> 
> This has already been discussed, and Fabrice mentioned support for .qmu files
> a while ago. To my knowledge, these have never been used and I don't know if
> they are still supported.
> 
> This approach would only work if all front-ends standardized to the same config
> file format, or if this parsing was done directly by the qemu engine ... or if
> all front ends invoked a standard parser to handle this. This would go along
> with the multiple process idea for the UI.

If we put this in the libqemu library from the get go, GUIs will use it.
If you notice how I modeled this in the header in my first email: You
generate a QEMUVirtualMachine from a QEMUVirtualMachineProfile which you
can load from a file or serialize to a file.  This standard struct would
be the standard place to define virtual machine parameters.

> I already have this, but it is done via a shell script that converts the
> parameters into command line options. It shouldn't be difficult to convert
> it into Python or Perl. (Writing a C program that does the same is also possible,
> and should be no more difficult than writing any other C program. ;)

It has to be C (portability without massive dependencies), though we may
want to use glib.  It has great functions for reading and writing config
files (in addition to a million other things).  glib is getting pretty
standard these days and has great Window support.  In fact, from what I
can see, glib would in some places reduce the code quite a bit in qemu.

Nathaniel