From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50081 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPxkg-0005Vm-1H for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:38:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPxke-00038t-Pi for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:38:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPxke-00038V-Hb for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:38:40 -0500 Message-ID: <4CFE38CB.10003@redhat.com> Date: Tue, 07 Dec 2010 14:38:19 +0100 From: Jes Sorensen MIME-Version: 1.0 References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <1291399402-20366-4-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1291399402-20366-4-git-send-email-mdroth@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v5 03/21] virtagent: common code for managing client/server rpc jobs List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com On 12/03/10 19:03, Michael Roth wrote: > This implements a simple state machine to manage client/server rpc > jobs being multiplexed over a single channel. > > A client job consists of sending an rpc request, reading an > rpc response, then making the appropriate callbacks. We allow one > client job to be processed at a time, which will make the following > state transitions: > > VA_CLIENT_IDLE -> VA_CLIENT_SEND (job queued, send channel open) > VA_CLIENT_SEND -> VA_CLIENT_WAIT (request sent, awaiting response) > VA_CLIENT_WAIT -> VA_CLIENT_IDLE (response recieved, callbacks made) > > A server job consists of recieving an rpc request, generating a > response, then sending the response. We expect to receive one server > request at a time due to the 1 at a time restriction for client jobs. > Server jobs make the following transitions: > > VA_SERVER_IDLE -> VA_SERVER_WAIT (recieved/executed request, send > channel busy, response deferred) > VA_SERVER_IDLE -> VA_SERVER_SEND (recieved/executed request, send > channel open, sending response) > VA_SERVER_WAIT -> VA_SERVER_SEND (send channel now open, sending > response) > VA_SERVER_SEND -> VA_SERVER_IDLE (response sent) > > Signed-off-by: Michael Roth As mentioned before, I really don't understand why this is part of QEMU, the guest agent really should be able to run totally outside of QEMU. > + > +#define DEBUG_VA > + > +#ifdef DEBUG_VA > +#define TRACE(msg, ...) do { \ > + fprintf(stderr, "%s:%s():L%d: " msg "\n", \ > + __FILE__, __FUNCTION__, __LINE__, ## __VA_ARGS__); \ > +} while(0) > +#else > +#define TRACE(msg, ...) \ > + do { } while (0) > +#endif > + > +#define LOG(msg, ...) do { \ > + fprintf(stderr, "%s:%s(): " msg "\n", \ > + __FILE__, __FUNCTION__, ## __VA_ARGS__); \ > +} while(0) This must be like the 217th copy of these functions, could you please use some of the code that is already in the tree, and make it generic if needed. > + > +#define VERSION "1.0" > +#define EOL "\r\n" > + > +#define VA_HDR_LEN_MAX 4096 /* http header limit */ > +#define VA_CONTENT_LEN_MAX 2*1024*1024 /* rpc/http send limit */ > +#define VA_CLIENT_JOBS_MAX 5 /* max client rpcs we can queue */ > +#define VA_SERVER_JOBS_MAX 1 /* max server rpcs we can queue */ As mentioned last time, please make this stuff configurable and not hard coded. Cheers, Jes