Hello everyone, I've actually tried to do some of these things myself a few months back. I thought I'd have a daemon or "control" program that would manage the QEMU instances.
A new instance would be launched by a controller app with a few of additional parameters. One is a custom window title (I added -t parameter support, which sets the title of the window). So if you had two QEMU instances open, the title of one would be "ABC" and the other would be "XYZ", or whatever you named that virtual computer in the control app. I found that while I was testing, having more than one QEMU window with the exact same title is less cumbersome. Also passed at startup was a unqiue ID string generated by the control app. It is used to identify that instance. Lastly, the control app passes it's own process ID. The the QEMU instance contacts the control app with it's unqiue ID, and then control app knows the process ID of the instance. From this point on the two processes can communicate with each other, since they know each other's process ID and can send messages. I then tried to modify the SDL sources and QEMU sources to support receiving messages sent to the window, similar to how (at least Windows) operating systems work. You can send an app's window a "minimize", "maximize", etc., messages and the app will respond to them. So I investigated and found that there is a range of commands set aside specifically for applications to use (they won't collide with system messages). So I figured I'd enumerate various QEMU commands into that region, such as savevm, etc. I then added code to the SDL/QEMU event loop to process those custom commands and translate them into the traditional commands and then let the event loop process the command as normal. It all worked, but my C/C++ is amateur enough that despite everything I tried my string parameters came through corrupt a good chunk of the time. And I've tried allocating my own memory, making copies of the parameter asap before it was deallocated by the OS, etc., but I never did get it stabilized before I ran out of time to work on it. The string is necessary for some commands, such as the loadvm/savevm to specify the path/filename of the image. With this support in QEMU, then any controlling application can easily manage QEMU transparently. Of course, it doesn't address wrapping controls around the QEMU window like VMWare does, but a controlling app would only need to implement a VNC client and map it to a window region or something to that effect, I suppose. I don't know much about the innerworkings of VNC but it seems plausible. -- James Funny quotes: "There are 10 types of people in the world. Those who understand binary, and those who don't." -- Unknown "A computer once beat me at chess, but it was no match for me at kick boxing." -- Emo Philips _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
