Re: [Qemu-devel] [RFC][PATCH v3 02/21] virtproxy: qemu-vp, standalone daemon skeleton

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 11/18/2010 04:04 AM, Stefan Hajnoczi wrote:
> On Tue, Nov 16, 2010 at 1:15 AM, Michael Roth<mdroth@linux.vnet.ibm.com>  wrote:
>> Daemon to be run in guest, or on host in standalone mode.
>> (re-)implements some qemu utility functions used by core virtproxy.c
>> code via wrapper functions. For built-in virtproxy code we will define
>> these wrapper functions in terms of qemu's built-in implementations.
>>
>> Main logic will come in a later patch.
>>
>> Signed-off-by: Michael Roth<mdroth@linux.vnet.ibm.com>
>> ---
>>   qemu-vp.c |  151 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 files changed, 151 insertions(+), 0 deletions(-)
>>   create mode 100644 qemu-vp.c
>
> Can you move IOHandlerRecord, main_loop_wait(), and friends out of
> vl.c and into a portable self-contained file that can be used both
> from qemu and virtproxy?
>
> Also, check out 0290b57bdfec83ca78b6d119ea9847bb17943328 which fixes a
> main_loo_wait() bug.  It was recently committed and didn't make it
> into qemu-vp.c.
>
> It would be unfortunate to duplicate this code.
>

Adam and Amit brought this up before as well...at the time it seemed 
like it'd be too invasive, since to be useful we'd need to be able to 
provide our own IOHandlerRecord list to main_loop_wait() and 
qemu_set_fd_handler(), which would require changes to widely used 
interfaces.

Since then Adam suggested something like:

int qemu_set_fd_handler(int fd,
                         IOHandler *fd_read,
                         IOHandler *fd_write,
                         void *opaque)
{
     return qemu_set_fd_handler_generic(vl.c:io_handlers, int fd, ...)
}

And similar for main_loop_wait() and friends, which looks pretty 
reasonable. Moving qemu-char.c:send_all() to a generally accessible 
place like qemu-sockets.c was another good candidate to share. That 
should remove most of the dupes...I'll try to work some patches for 
these into the next round.

> Stefan