[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU feature idea: simple macros/scripting
From: |
Johannes Schindelin |
Subject: |
Re: [Qemu-devel] QEMU feature idea: simple macros/scripting |
Date: |
Fri, 1 Oct 2004 11:54:07 +0200 (CEST) |
Hi,
On Thu, 30 Sep 2004, John R. Hogerhuis wrote:
> On Thu, 2004-09-30 at 17:19, Johannes Schindelin wrote:
>
> > I started to write a vnc frontend for QEmu. On the other end, I started to
> > write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> > but also Macros/Scripting for everything which can be controlled by a
> > vncviewer. For now, I use an adaption of vncrec, which just records inputs
> > and timestamps, and play those inputs back later.
>
> Sounds like your solution would work for me as well. I hadn't thought of
> using vnc and related tools.
>
> I'm not sure what kind of integration makes sense, if any.
>
> A record/playback feature could be
>
> 1) In QEMU proper wedged between the QEMU and the guest, hooked into the
> data traffic
You would probably not even need that much, but just write your own
frontend (see vnc.c, or no-sdl hack for examples). Maybe a scriptable
frontend via SWIG; the main application loop would probably have to run in
an own thread.
> 2) In a front end to QEMU which just communicates through a
> to-be-implemented API; basically still #1 just architecturally different
well, actually not different, but better separated.
> 3) In a completely separate utility that knows nothing about QEMU and
> just deals with X. Such utilities exist for X
See for example xautomation: http://hoopajoo.net/projects/xautomation.html
> 4) In a VNC viewer
See my work in a few weeks/months.
> 5) In the guest only; such utilities exist for Windows and probably some
> other OSes.
>
> Not sure what the pros/cons are exactly. (5) can be ruled out since you
> wouldn't be able to script at the QEMU level (saving/loading system
> state images and such [...])
Well, not exactly true. You can run a job which looks on the second hard
drive (if that exists) for a script, and then savevm. When you now run
qemu loadvm'ing that state, you supply a second hard drive image et voila!
Ciao,
Dscho