* [Qemu-devel] Just a thought (high level API)
@ 2005-02-09 15:09 Nathaniel McCallum
2005-02-09 15:52 ` McMullan, Jason
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-09 15:09 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
I know a lot of people are wanting to build qemu frontends and embedding
the sdl window has been a frustration to several. Well, I was just
thinking today, what if we moved most of the emulation code behind a
high level api, creating "libqemu" which would allow for lots of things
including multiple frontends, embeded qemu, etc. I brainstormed up a
*very* raw idea yesterday between my classes while taking a very cursory
glance at the code. I had three goals:
1. Create a library (duh!)
2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)
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...)
Attached below is a header containing a first crack at a libqemu api.
Nathaniel
[-- Attachment #2: Type: text/x-chdr, Size: 6600 bytes --]
/*
* The basic idea of the API below is to allow Frontends to provide their own
* method of device control (ie. QEMUDisplayControl) and allowing users to
* provide the virtual machine settings via a saveable profile. Thus:
* ${virtual_machine_profile} + ${device_control} == virtual machine.
* Advantages a basic library as a backend include:
* - Code reuse
* - Plugin "drivers" (ie. SDL, Xv, GTK/GDK, QT, etc...)
* - Various frontends for different tasks
* - Embedded QEMU :)
* - Others...
* This API is incomplete and is just the result of a brainstorming session.
* As this idea is version 0.0.0.0.1 ;), feel free to make suggestions, etc.
*/
#ifndef FALSE
#define FALSE 0
#define TRUE !FALSE
typedef int bool;
#endif
#define DISK_TYPE_HDD 0
#define DISK_TYPE_CDROM 1
#define DISK_TYPE_FLOPPY 2
#define NET_TYPE_DUMMY 0
#define NET_TYPE_USER 1
#ifndef _WIN32
#define NET_TYPE_TUN 2
#endif
#define PROTOCOL_UDP 0
#define PROTOCOL_TCP 1
#define FDA 0
#define FDB 1
#define HDA 2
#define HDB 3
#define HDC 4
#define HDD 5
/*
* A structure holding the current display state.
* All members are private and all changes should be made through the methods
* in QEMUDisplayPlugin (ie. called by libqemu).
*/
typedef struct {
uint8_t *data;
int linesize;
int depth;
int width;
int height;
bool fullscreen;
} QEMUDisplayState;
/*
* This struct is basically a plugin for different video sinks. No matter
* what output method you are using (SDL,Xv,GDK/GTK,etc), just use this struct
* to allow QEMU to control your display.
*/
typedef struct {
/* Initializes the display. Returns FALSE on failure, TRUE on success) */
bool (*dpy_init) (QEMUDisplayState *ds);
/* Enters fullscreen mode */
void (*dpy_fullscreen_on) (QEMUDisplayState *ds);
/* Exits fullscreen mode */
void (*dpy_fullscreen_off) (QEMUDisplayState *ds);
/* Grabs the keyboard and mouse */
void (*dpy_grab) (QEMUDisplayState *ds);
/* Releases the keyboard and mouse */
void (*dpy_ungrab) (QEMUDisplayState *ds);
/* I'm not really sure what this does... update vs refresh? */
void (*dpy_update) (QEMUDisplayState *ds);
/* Resizes the display to specified size */
void (*dpy_resize) (QEMUDisplayState *ds, int width, int height);
/* I'm not really sure what this does either... update vs refresh? */
void (*dpy_refresh) (QEMUDisplayState *ds);
/* Called upon closing the display. After calling this, dpy_init must
* be called again for any further activity. */
void (*dpy_end) (QEMUDisplayState *ds);
} QEMUDisplayControl;
/*
* Structure which represents a drive or drive image.
*/
typedef struct {
char *device_file;
int device_type; /* ie. DISK_TYPE_CDROM */
bool snapshot; /* enables snapshot mode on this device */
} QEMUDriveProfile;
/*
* Structure representing a redirection
*/
typedef struct {
int type; /* ie. PROTOCOL_TCP */
int host_port;
char *guest_ip;
int guest_port;
} QEMUNetworkRedirectionProfile;
/*
* Structure which represents a network setup.
*/
typedef struct {
/* A NULL terminated vector of mac addresses.
* Only first x nics will be allowed (others ignored). */
uint8_t **macaddr;
/* The type of network access we will use. */
int network_type; /* ie. NET_TYPE_USER */
#ifndef _WIN32
/* The file descriptor of an already open tap/tun interface */
int tun_fd;
/* The script used to bring up a tap/tun interface */
char *tun_script;
/* Allow tftp access to the files starting with this prefix */
char *tftp_prefix;
/* Allow samba access to the files in this dir */
char *smb_dir;
#endif
/* A NULL terminated vector of redirections */
QEMUNetworkRedirectionProfile **redir;
} QEMUNetworkProfile;
/*
* Represents a Virtual Machine.
*/
typedef struct {
/**
*** Metadata
**/
/* The name of the virtual machine. */
char *name;
/**
*** Core Hardware
**/
/* Our drives. If a particular drive is not set, it *MUST* == NULL
* ie. to unset 'hda': x->drives[HDA] = NULL */
QEMUDriveProfile *drives[6];
/* Our network setup */
QEMUNetworkProfile *network;
/* The ammount of memory for the virtual machine in megabytes */
int mb_memory;
/**
*** Hardware options
**/
/* Whether or not audio support is enabled. Perhaps we want a
* QEMUAudioControl plugin instead (or in addition)? */
bool enable_audio;
/* Whether or not to enable localtime for the guest */
bool guestclock_localtime;
/* Takes a DISK_TYPE and boots the first device matching that type */
int boot_type; /* ie. DISK_TYPE_CDROM */
/* The keyboard map to use. */
char *keyboard_map;
/* Whether or not to start the Virtual Machine in fullscreen mode */
bool fullscreen_on_start;
/* Enables pci emulation */
bool emulate_pci;
/**
*** Boot options
**/
/* Options for booting a specific kernel */
char *bzImage;
char *cmdline;
char *initrd;
/* Define custom BIOS locations */
char *sys_bios;
char *vga_bios;
} QEMUVirtualMachineProfile;
typedef struct {
unsigned int id; /* Do we need this? */
QEMUDisplayControl *display;
QEMUVirtualMachineProfile *profile;
bool frozen;
/* Others? */
} QEMUVirtualMachine;
/* Does any pre-emu tasks including compiling a QEMUVirtualMachine instance.
* Returns null on failure */
QEMUVirtualMachine *qemu_vm_init (QEMUVirtualMachineProfile *vmp,
QEMUDisplayControl *dc /*,
??QEMUAudioControl *ac?? */);
/* Starts (or resumes) emulation */
void qemu_vm_start(QEMUVirtualMachine *vm);
/* Pauses emulation (use qemu_vm_start() to resume) */
void qemu_vm_pause(QEMUVirtualMachine *vm);
/* Resets virtual machine */
void qemu_vm_reset(QEMUVirtualMachine *vm);
/* Closes virtual machine. qemu_vm_init() must be called again before
* restarting emulation. */
void qemu_vm_quit(QEMUVirtualMachine *vm);
/* Commit snapshots to disk. disk = [FDA|FDB|HDA|HDB|HDC|HDD|-1] */
void qemu_vm_commit(QEMUVirtualMachine *vm, int disk);
/* Ejects a disk */
void qemu_vm_eject(QEMUVirtualMachine *vm, int disk);
/* Dumps the screen to a ppm image */
bool qemu_vm_screendump(QEMUVirtualMachine *vm, char *filename);
/* Save and load the state of the VM */
bool qemu_vm_savevm(QEMUVirtualMachine *vm, char *filename);
bool qemu_vm_loadvm(QEMUVirtualMachine *vm, char *filename);
/* Send keys */
void qemu_vm_sendkey(QEMUVirtualMachine *vm, char *keys);
/* ...and others (ie. gdb stuff, etc)... */
/* A standard way to save and load virtual machines (XML?, .INI-style?).
* This is usable by all front ends no matter what toolkit. */
QEMUVirtualMachineProfile *qemu_vmp_load(char *filename);
bool qemu_vmp_save(QEMUVirtualMachineProfile *vmp, char *filename);
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-09 15:09 [Qemu-devel] Just a thought (high level API) Nathaniel McCallum
@ 2005-02-09 15:52 ` McMullan, Jason
2005-02-10 0:02 ` Jim C. Brown
2005-02-10 19:59 ` Fabrice Bellard
2 siblings, 0 replies; 22+ messages in thread
From: McMullan, Jason @ 2005-02-09 15:52 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
On Wed, 2005-02-09 at 10:09 -0500, Nathaniel McCallum wrote:
> Attached below is a header containing a first crack at a libqemu api.
Woot!
This would be wonderful to add as an optional module to u-boot to allow
the initialization of PCI Video cards!
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-09 15:09 [Qemu-devel] Just a thought (high level API) Nathaniel McCallum
2005-02-09 15:52 ` McMullan, Jason
@ 2005-02-10 0:02 ` Jim C. Brown
2005-02-10 1:28 ` Nathaniel McCallum
2005-02-10 19:59 ` Fabrice Bellard
2 siblings, 1 reply; 22+ messages in thread
From: Jim C. Brown @ 2005-02-10 0:02 UTC (permalink / raw)
To: qemu-devel
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.
> Well, I was just
> thinking today, what if we moved most of the emulation code behind a
> high level api, creating "libqemu" which would allow for lots of things
> including multiple frontends, embeded qemu, etc. I brainstormed up a
> *very* raw idea yesterday between my classes while taking a very cursory
> glance at the code. I had three goals:
> 1. Create a library (duh!)
There already exists a libqemu.a file that seems to support this. That may
be qemu-user specific however.
> 2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)
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.
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).
> 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".
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 0:02 ` Jim C. Brown
@ 2005-02-10 1:28 ` Nathaniel McCallum
2005-02-10 2:34 ` Jim C. Brown
0 siblings, 1 reply; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-10 1:28 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 4549 bytes --]
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
[-- Attachment #2: libqemu.png --]
[-- Type: image/png, Size: 42987 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 1:28 ` Nathaniel McCallum
@ 2005-02-10 2:34 ` Jim C. Brown
2005-02-10 3:47 ` Nathaniel McCallum
0 siblings, 1 reply; 22+ messages in thread
From: Jim C. Brown @ 2005-02-10 2:34 UTC (permalink / raw)
To: qemu-devel
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
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 2:34 ` Jim C. Brown
@ 2005-02-10 3:47 ` Nathaniel McCallum
0 siblings, 0 replies; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-10 3:47 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-09 15:09 [Qemu-devel] Just a thought (high level API) Nathaniel McCallum
2005-02-09 15:52 ` McMullan, Jason
2005-02-10 0:02 ` Jim C. Brown
@ 2005-02-10 19:59 ` Fabrice Bellard
2005-02-10 20:32 ` Nathaniel McCallum
2 siblings, 1 reply; 22+ messages in thread
From: Fabrice Bellard @ 2005-02-10 19:59 UTC (permalink / raw)
To: qemu-devel
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. Well, I was just
> thinking today, what if we moved most of the emulation code behind a
> high level api, creating "libqemu" which would allow for lots of things
> including multiple frontends, embeded qemu, etc. I brainstormed up a
> *very* raw idea yesterday between my classes while taking a very cursory
> glance at the code. I had three goals:
> 1. Create a library (duh!)
> 2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)
> 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...)
>
> Attached below is a header containing a first crack at a libqemu api.
Such a high level API is a good idea and I plan to add one, but it is
not my priority right now. It is not a necessary condition to have
multiple GUIs or support for configuration files. Moreover, I don't want
the GUI to be an external project for QEMU - the GUI is an integral part
of a program, and I prefer to have one finished GUI than 5 half finished
ones :-)
As a summary I prefer first to have a GUI and then to make some clean up
to support it. The reverse approach often leads to "overdesign" i.e.
bloated code.
Just another point as it was mentionned in the thread: I agree that some
kind of dynamic modules are needed in QEMU - they will come someday. At
the current point I am relunctant to add them to avoid fragmenting the
project and to have to ensure binary compatibility: QEMU is not mature
enough yet.
Fabrice.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 19:59 ` Fabrice Bellard
@ 2005-02-10 20:32 ` Nathaniel McCallum
2005-02-10 21:21 ` Fabrice Bellard
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-10 20:32 UTC (permalink / raw)
To: qemu-devel
On Thu, 2005-02-10 at 20:59 +0100, Fabrice Bellard wrote:
> 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. Well, I was just
> > thinking today, what if we moved most of the emulation code behind a
> > high level api, creating "libqemu" which would allow for lots of things
> > including multiple frontends, embeded qemu, etc. I brainstormed up a
> > *very* raw idea yesterday between my classes while taking a very cursory
> > glance at the code. I had three goals:
> > 1. Create a library (duh!)
> > 2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)
> > 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...)
> >
> > Attached below is a header containing a first crack at a libqemu api.
>
> Such a high level API is a good idea and I plan to add one, but it is
> not my priority right now. It is not a necessary condition to have
> multiple GUIs or support for configuration files. Moreover, I don't want
> the GUI to be an external project for QEMU - the GUI is an integral part
> of a program, and I prefer to have one finished GUI than 5 half finished
> ones :-)
>
> As a summary I prefer first to have a GUI and then to make some clean up
> to support it. The reverse approach often leads to "overdesign" i.e.
> bloated code.
>
> Just another point as it was mentionned in the thread: I agree that some
> kind of dynamic modules are needed in QEMU - they will come someday. At
> the current point I am relunctant to add them to avoid fragmenting the
> project and to have to ensure binary compatibility: QEMU is not mature
> enough yet.
Thanks for your input! I was hoping you'd come out and play ;). I'll
gladly do a gtk frontend (I was planning on it). However, one of the
first things I would need to do would be to create some kind of config
file to store the settings in. I'd rather do this upstream and let
other front ends benefit from this as well.
I'm also curious as to your opinion on glib. I've noticed several
places in the code where qemu has reimplimented several things that
would be much simpler to just use glib for (with its wide os-independant
support). Particularly: string functions, error reporting, main loops,
memory allocation, etc. As a test, I've been going through qemu-img.c
converting it to glib. So far I've got about 100 lines less code and
I'm only a quarter of the way through the file. Do you have any
objections to a glib dependency?
Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 20:32 ` Nathaniel McCallum
@ 2005-02-10 21:21 ` Fabrice Bellard
2005-02-10 22:16 ` Magnus Damm
2005-02-11 11:07 ` Jan Marten Simons
2 siblings, 0 replies; 22+ messages in thread
From: Fabrice Bellard @ 2005-02-10 21:21 UTC (permalink / raw)
To: qemu-devel
Nathaniel McCallum wrote:
> [...] As a test, I've been going through qemu-img.c
> converting it to glib. So far I've got about 100 lines less code and
> I'm only a quarter of the way through the file. Do you have any
> objections to a glib dependency?
Yes. I prefer to avoid dependencies when possible. Of course the GTK GUI
itself should use glib.
Fabrice.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 20:32 ` Nathaniel McCallum
2005-02-10 21:21 ` Fabrice Bellard
@ 2005-02-10 22:16 ` Magnus Damm
2005-02-11 11:07 ` Jan Marten Simons
2 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2005-02-10 22:16 UTC (permalink / raw)
To: qemu-devel
On Thu, 10 Feb 2005 15:32:44 -0500, Nathaniel McCallum
<npmccallum@gentoo.org> wrote:
[snip]
> Thanks for your input! I was hoping you'd come out and play ;). I'll
> gladly do a gtk frontend (I was planning on it). However, one of the
> first things I would need to do would be to create some kind of config
> file to store the settings in. I'd rather do this upstream and let
> other front ends benefit from this as well.
Please implement a gtk frontend, that would be really cool and useful!
And speaking about config files, I think extending the current way of
passing options to the system emulator further leads to is a dead end:
http://lists.gnu.org/archive/html/qemu-devel/2005-01/msg00175.html
I would like to see more reentrant code that makes it possible to have
several instances of the same code hooked up at different places in
the emulator. Code that emulates hardware is of course a candidate,
but I also think displaying and muxing graphics is a typical thing
that a user wants to control from somewhere. Say that I would like to
emulate a system with two vga cards - where should the output go? To
one window and to /dev/null? Or two windows? Or muxed together like
the vga output and the monitor in one window? I think the best is to
let the user decide.
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-10 20:32 ` Nathaniel McCallum
2005-02-10 21:21 ` Fabrice Bellard
2005-02-10 22:16 ` Magnus Damm
@ 2005-02-11 11:07 ` Jan Marten Simons
2005-02-11 12:20 ` Johannes Schindelin
2 siblings, 1 reply; 22+ messages in thread
From: Jan Marten Simons @ 2005-02-11 11:07 UTC (permalink / raw)
To: qemu-devel
Nathaniel McCallum wrote:
>I'm also curious as to your opinion on glib. I've noticed several
>places in the code where qemu has reimplimented several things that
>would be much simpler to just use glib for (with its wide os-independant
>support). Particularly: string functions, error reporting, main loops,
>memory allocation, etc. As a test, I've been going through qemu-img.c
>converting it to glib. So far I've got about 100 lines less code and
>I'm only a quarter of the way through the file. Do you have any
>objections to a glib dependency?
>
>Nathaniel
>
>
>
I wouldn't mind a glibc-build-time-dependency, but a runtime dependency
would be really bad imho, as right now you can start qemu from a very
stripped-down system just by its binary.
But I agree with Fabrice that keeping as little dependencies as possible
is a good thing.
Jan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 11:07 ` Jan Marten Simons
@ 2005-02-11 12:20 ` Johannes Schindelin
2005-02-11 15:07 ` Jim C. Brown
2005-02-11 18:27 ` [Qemu-devel] " Jan Marten Simons
0 siblings, 2 replies; 22+ messages in thread
From: Johannes Schindelin @ 2005-02-11 12:20 UTC (permalink / raw)
To: qemu-devel
Hi,
On Fri, 11 Feb 2005, Jan Marten Simons wrote:
> I wouldn't mind a glibc-build-time-dependency, [...]
I think they talked about glib, not glibc. glib is sort of a utility
library for gtk, which contains things like containers.
Hth,
Dscho
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 12:20 ` Johannes Schindelin
@ 2005-02-11 15:07 ` Jim C. Brown
2005-02-11 15:35 ` Nathaniel McCallum
2005-02-11 18:27 ` [Qemu-devel] " Jan Marten Simons
1 sibling, 1 reply; 22+ messages in thread
From: Jim C. Brown @ 2005-02-11 15:07 UTC (permalink / raw)
To: qemu-devel
On Fri, Feb 11, 2005 at 01:20:12PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 11 Feb 2005, Jan Marten Simons wrote:
>
> > I wouldn't mind a glibc-build-time-dependency, [...]
>
> I think they talked about glib, not glibc. glib is sort of a utility
> library for gtk, which contains things like containers.
GTK has high level GUI widgets, GDK is the lower level event and graphics
layer, and glib is the really low level stuff.
glib is mainly a library used for portability (such as a cross platform
libdl interface or platform independent fixed-size types) and can be used
w/o having to bring in all the code used for a graphical interface.
Obviously, qemu will always have a glibc-build-time-dependency, and it will
also have glibc as a run time dependency (unless it is staticly linked like
qemu-fast was).
>
> Hth,
> Dscho
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 15:07 ` Jim C. Brown
@ 2005-02-11 15:35 ` Nathaniel McCallum
2005-02-11 16:14 ` [Qemu-devel] " Ronald
0 siblings, 1 reply; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-11 15:35 UTC (permalink / raw)
To: qemu-devel
On Fri, 2005-02-11 at 10:07 -0500, Jim C. Brown wrote:
>glib is mainly a library used for portability (such as a cross platform
>libdl interface or platform independent fixed-size types) and can be used
>w/o having to bring in all the code used for a graphical interface.
It also provides all kind of data types (linked lists, autosizing
vectors), error reporting (like exceptions), main loops, os independant
threading, queues, message logging, and all kinds of other really useful
stuff that most people just impliment in C in most projects anyway.
glib actually has nothing to do with GTK other than the fact that
several of the same people work on it and GTK uses glib. glib is used
in all kinds of other utilities and is usually part of a base linux
system. Its generally a dependency that most people have. In addition,
it saves a lot of #ifdef _WIN32 type stuff, as it is platform
independant.
Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Qemu-devel] Re: Just a thought (high level API)
2005-02-11 15:35 ` Nathaniel McCallum
@ 2005-02-11 16:14 ` Ronald
2005-02-11 23:02 ` Nathaniel McCallum
0 siblings, 1 reply; 22+ messages in thread
From: Ronald @ 2005-02-11 16:14 UTC (permalink / raw)
To: qemu-devel
Hi,
Le Fri, 11 Feb 2005 10:35:36 -0500, Nathaniel McCallum a écrit :
> On Fri, 2005-02-11 at 10:07 -0500, Jim C. Brown wrote:
>>glib is mainly a library used for portability (such as a cross platform
>>libdl interface or platform independent fixed-size types) and can be used
>>w/o having to bring in all the code used for a graphical interface.
>
> It also provides all kind of data types (linked lists, autosizing
> vectors), error reporting (like exceptions), main loops, os independant
> threading, queues, message logging, and all kinds of other really useful
> stuff that most people just impliment in C in most projects anyway. glib
> actually has nothing to do with GTK other than the fact that several of
> the same people work on it and GTK uses glib. glib is used in all kinds
> of other utilities and is usually part of a base linux system. Its
> generally a dependency that most people have. In addition, it saves a lot
> of #ifdef _WIN32 type stuff, as it is platform independant.
>
> Nathaniel
>From my point of view having a dependancy on glib may cause much trouble
for specific build, windows one to be precise. glib introduce a few other
dependancies like libintl, libiconv and (not sure) libxml2, so even when
building in native environment you'll have to have a lot of prerequisite
to be able to build qemu.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Re: Just a thought (high level API)
2005-02-11 16:14 ` [Qemu-devel] " Ronald
@ 2005-02-11 23:02 ` Nathaniel McCallum
2005-02-11 23:39 ` [Qemu-devel] " Ronald
0 siblings, 1 reply; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-11 23:02 UTC (permalink / raw)
To: daimon55, qemu-devel
Ronald wrote:
> Hi,
>
> Le Fri, 11 Feb 2005 10:35:36 -0500, Nathaniel McCallum a écrit :
>
>
>>On Fri, 2005-02-11 at 10:07 -0500, Jim C. Brown wrote:
>>
>>>glib is mainly a library used for portability (such as a cross platform
>>>libdl interface or platform independent fixed-size types) and can be used
>>>w/o having to bring in all the code used for a graphical interface.
>>
>>It also provides all kind of data types (linked lists, autosizing
>>vectors), error reporting (like exceptions), main loops, os independant
>>threading, queues, message logging, and all kinds of other really useful
>>stuff that most people just impliment in C in most projects anyway. glib
>>actually has nothing to do with GTK other than the fact that several of
>>the same people work on it and GTK uses glib. glib is used in all kinds
>>of other utilities and is usually part of a base linux system. Its
>>generally a dependency that most people have. In addition, it saves a lot
>>of #ifdef _WIN32 type stuff, as it is platform independant.
>>
>>Nathaniel
>
>
>>From my point of view having a dependancy on glib may cause much trouble
> for specific build, windows one to be precise. glib introduce a few other
> dependancies like libintl, libiconv and (not sure) libxml2, so even when
> building in native environment you'll have to have a lot of prerequisite
> to be able to build qemu.
glib has no dependencies on my system other than glibc. Is that a
windows specific dependency?
Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Qemu-devel] Re: Re: Just a thought (high level API)
2005-02-11 23:02 ` Nathaniel McCallum
@ 2005-02-11 23:39 ` Ronald
0 siblings, 0 replies; 22+ messages in thread
From: Ronald @ 2005-02-11 23:39 UTC (permalink / raw)
To: qemu-devel
Le Fri, 11 Feb 2005 18:02:36 -0500, Nathaniel McCallum a écrit :
>>>It also provides all kind of data types (linked lists, autosizing
>>>vectors), error reporting (like exceptions), main loops, os independant
>>>threading, queues, message logging, and all kinds of other really useful
>>>stuff that most people just impliment in C in most projects anyway. glib
>>>actually has nothing to do with GTK other than the fact that several of
>>>the same people work on it and GTK uses glib. glib is used in all kinds
>>>of other utilities and is usually part of a base linux system. Its
>>>generally a dependency that most people have. In addition, it saves a
>>>lot of #ifdef _WIN32 type stuff, as it is platform independant.
>>>
>>>Nathaniel
>>
>>
>>>From my point of view having a dependancy on glib may cause much trouble
>> for specific build, windows one to be precise. glib introduce a few
>> other dependancies like libintl, libiconv and (not sure) libxml2, so
>> even when building in native environment you'll have to have a lot of
>> prerequisite to be able to build qemu.
>
> glib has no dependencies on my system other than glibc. Is that a windows
> specific dependency?
>
glibc2 already implement functions like iconv() by itself, that's why
there is no need for other libs, but for windows it's needed to provide
the missing functions.
> Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 12:20 ` Johannes Schindelin
2005-02-11 15:07 ` Jim C. Brown
@ 2005-02-11 18:27 ` Jan Marten Simons
2005-02-11 18:30 ` Paul Brook
1 sibling, 1 reply; 22+ messages in thread
From: Jan Marten Simons @ 2005-02-11 18:27 UTC (permalink / raw)
To: qemu-devel
Johannes Schindelin wrote:
>>I wouldn't mind a glibc-build-time-dependency, [...]
>>
>>
>
>I think they talked about glib, not glibc. glib is sort of a utility
>library for gtk, which contains things like containers.
>
>
>
Oh, my bad, I misread it then. But my point is still valid. I don't mind
additional dependencies, as long as those are only needed during
compilation and those would be helpful for qemu and not restricting its
compilation on various OS/arch.
Jan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 18:27 ` [Qemu-devel] " Jan Marten Simons
@ 2005-02-11 18:30 ` Paul Brook
2005-02-11 20:03 ` Nathaniel McCallum
0 siblings, 1 reply; 22+ messages in thread
From: Paul Brook @ 2005-02-11 18:30 UTC (permalink / raw)
To: qemu-devel
On Friday 11 February 2005 18:27, Jan Marten Simons wrote:
> Johannes Schindelin wrote:
> >>I wouldn't mind a glibc-build-time-dependency, [...]
> >
> >I think they talked about glib, not glibc. glib is sort of a utility
> >library for gtk, which contains things like containers.
>
> Oh, my bad, I misread it then. But my point is still valid. I don't mind
> additional dependencies, as long as those are only needed during
> compilation and those would be helpful for qemu and not restricting its
> compilation on various OS/arch.
glib is a shared library on my system, so would introduce a runtime
dependency.
Paul
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 18:30 ` Paul Brook
@ 2005-02-11 20:03 ` Nathaniel McCallum
2005-02-11 22:55 ` art yerkes
0 siblings, 1 reply; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-11 20:03 UTC (permalink / raw)
To: qemu-devel
On Fri, 2005-02-11 at 18:30 +0000, Paul Brook wrote:
>On Friday 11 February 2005 18:27, Jan Marten Simons wrote:
>> Johannes Schindelin wrote:
>> >>I wouldn't mind a glibc-build-time-dependency, [...]
>> >
>> >I think they talked about glib, not glibc. glib is sort of a utility
>> >library for gtk, which contains things like containers.
>>
>> Oh, my bad, I misread it then. But my point is still valid. I don't mind
>> additional dependencies, as long as those are only needed during
>> compilation and those would be helpful for qemu and not restricting its
>> compilation on various OS/arch.
>
>glib is a shared library on my system, so would introduce a runtime
>dependency.
It is generally a shared library on most systems. However, most systems
should have a copy of it installed by default. dbus requires it (maybe
hal as well) as well as a bunch of other non-gtk/gnome apps.
I'm curious, does anyone *not* have it already installed? A simple
"locate libglib-2.0" should suffice to tell you. glib should not have
any dependencies itself other than libc and maybe pkg-config.
Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 20:03 ` Nathaniel McCallum
@ 2005-02-11 22:55 ` art yerkes
2005-02-11 23:04 ` Nathaniel McCallum
0 siblings, 1 reply; 22+ messages in thread
From: art yerkes @ 2005-02-11 22:55 UTC (permalink / raw)
To: qemu-devel
On Fri, 11 Feb 2005 15:03:56 -0500
Nathaniel McCallum <npmccallum@gentoo.org> wrote:
> I'm curious, does anyone *not* have it already installed? A simple
> "locate libglib-2.0" should suffice to tell you. glib should not have
> any dependencies itself other than libc and maybe pkg-config.
Some linux users install up from a small base system. In such cases
(like mine) they won't have glib.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Just a thought (high level API)
2005-02-11 22:55 ` art yerkes
@ 2005-02-11 23:04 ` Nathaniel McCallum
0 siblings, 0 replies; 22+ messages in thread
From: Nathaniel McCallum @ 2005-02-11 23:04 UTC (permalink / raw)
To: art yerkes; +Cc: qemu-devel
art yerkes wrote:
> On Fri, 11 Feb 2005 15:03:56 -0500
> Nathaniel McCallum <npmccallum@gentoo.org> wrote:
>
>
>>I'm curious, does anyone *not* have it already installed? A simple
>>"locate libglib-2.0" should suffice to tell you. glib should not have
>>any dependencies itself other than libc and maybe pkg-config.
>
>
> Some linux users install up from a small base system. In such cases
> (like mine) they won't have glib.
I know what building up from a small system is, I'm a gentoo developer
;) (That is all we ever do). I think glib gets pulled into our base
system, but that may be a USE flag thing.
Nathaniel
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-02-11 23:57 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-09 15:09 [Qemu-devel] Just a thought (high level API) Nathaniel McCallum
2005-02-09 15:52 ` McMullan, Jason
2005-02-10 0:02 ` Jim C. Brown
2005-02-10 1:28 ` Nathaniel McCallum
2005-02-10 2:34 ` Jim C. Brown
2005-02-10 3:47 ` Nathaniel McCallum
2005-02-10 19:59 ` Fabrice Bellard
2005-02-10 20:32 ` Nathaniel McCallum
2005-02-10 21:21 ` Fabrice Bellard
2005-02-10 22:16 ` Magnus Damm
2005-02-11 11:07 ` Jan Marten Simons
2005-02-11 12:20 ` Johannes Schindelin
2005-02-11 15:07 ` Jim C. Brown
2005-02-11 15:35 ` Nathaniel McCallum
2005-02-11 16:14 ` [Qemu-devel] " Ronald
2005-02-11 23:02 ` Nathaniel McCallum
2005-02-11 23:39 ` [Qemu-devel] " Ronald
2005-02-11 18:27 ` [Qemu-devel] " Jan Marten Simons
2005-02-11 18:30 ` Paul Brook
2005-02-11 20:03 ` Nathaniel McCallum
2005-02-11 22:55 ` art yerkes
2005-02-11 23:04 ` Nathaniel McCallum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).