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

[Jim C. Brown]

On Wed, Feb 09, 2005 at 08:28:08PM -0500, Nathaniel McCallum wrote:
> 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.

Ok I see what you are saying now.

> 
> 
> >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.
> 

Actually I was talking about such a high level api. The existing sound api
and the proposed GUI api that I mentioned have nothing to do with the sound
card or video card emulation.

The main difference between your idea and mine is that my API would make the
drivers part of the compile process (they would have to be built into qemu)
while yours wouldn't need this. (Using dynamiclly linked libraries would
remove the build requirement, but the main qemu executable would still be the
primary executable).

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.

> 
> >
> >>   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.

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.

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. ;)

> 
> Nathaniel


> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.