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

[Michael Roth]

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