[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RFC][PATCH v5 00/21] virtagent: host/guest RPC com

From: Michael Roth
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
Date: Tue, 07 Dec 2010 08:29:10 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20101027 Thunderbird/3.1.6

On 12/07/2010 04:24 AM, Jes Sorensen wrote:
On 12/03/10 19:03, Michael Roth wrote:
These patches apply to master, and can also be obtained from:
git://repo.or.cz/qemu/mdroth.git virtagent_v5


  - Dependency on virtproxy dropped, virtagent now handles transport and 
multiplexing of bi-directional RPCs internally
  - Removed duplification of qemu_set_fd_handler()-centered i/o code. Support 
for interacting with objects that use qemu_set_fd_handler() now available to 
tools via qemu-tools.c and a set of generalized utility functions
  - Fixed memory leaks in client/monitor functions
  - Various cleanups

Hi Michael,

Does this mean that virtproxy is now obsolete, or does it just mean
using virtproxy is optional?

As far as virtagent goes it is obsolete, and without the guest-side bits of virtproxy being integrated into the guest agent I don't see it being very useful at this point.

I would still prefer to have virtagent a separate package, rather than
part of the QEMU tree though.

There's a client and server in qemu, and a client and server in the agent, and all that code is shared. So even if we were to have a seperate tree for the agent, 90% of the code would also be sitting in the qemu tree anyway. I wouldn't mind hosting it outside of qemu but given what we're trying to do there's not a whole lot to be gained from it.

I agree it'd make sense if virtagent wasn't bidirectional since then there'd be a clean separation between qemu (client) and virtagent (server), and it would have the added benefit of enforcing consistent/stable client/server APIs between versions, but that's not the case here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]