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
CHANGES IN 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.
Thanks,
Jes