From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CDc4V-0008F9-78 for qemu-devel@nongnu.org; Sat, 02 Oct 2004 01:04:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CDc4U-0008Ex-P3 for qemu-devel@nongnu.org; Sat, 02 Oct 2004 01:04:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CDc4U-0008Eu-Ln for qemu-devel@nongnu.org; Sat, 02 Oct 2004 01:04:38 -0400 Received: from [216.254.0.205] (helo=mail5.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CDbxj-0003VV-Ub for qemu-devel@nongnu.org; Sat, 02 Oct 2004 00:57:40 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 2 Oct 2004 04:57:36 -0000 Subject: Re: [Qemu-devel] QEMU feature idea: simple macros/scripting From: "John R. Hogerhuis" In-Reply-To: References: <1096588555.10585.42.camel@aragorn> <1096602009.10585.62.camel@aragorn> Content-Type: text/plain Message-Id: <1096693115.30294.29.camel@aragorn> Mime-Version: 1.0 Date: Fri, 01 Oct 2004 21:58:35 -0700 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, 2004-10-01 at 02:54, Johannes Schindelin wrote: > > 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! > Actually in that direction, it strikes me that the guest is the most efficient and accurate place to record events, if at all possible, since then, say instead of recording a mouse position and a button click, the recorder instead saves the window id of the button and the message that goes to it. And it would be more likely to work properly even if a window shows up in a different place on a given run than the other possible solutions. In that case it would make sense to design a formal communication channel between QEMU and a player/recorder piece running in the guest, so that QEMU could send/receive portions of the script that must run in the guest and get notified at transition points (including exceptional occurences) so QEMU could execute portions of the script only it can (like savevm). VmWare has "Vmware Tools" which run in the guest, which adds remote control of the graphics driver among other things. From what Lionel said, it sounds like there is something that is part of the WINE project which could be utilized here, and it could be made part of a package for QEMU analogous to VmWare Tools. -- John.