Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands

[Mark McLoughlin <markmc@redhat.com>]

On Tue, 2009-07-21 at 21:20 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > My take on it is that we're all agreed that it's never valid with the
> > current monitor protocol for a client to queue up multiple fds. It's a
> > synchronous protocol, you can't send multiple commands at once.
> >   
> 
> I think there's a subtle point that was lost in the thread.  While we'll 
> only need to queue one fd per MonitorState, we'll still need to deal 
> with multiple fds per CharDriverState.

Why? For a theoretical use case, or for the current monitor interface?

If the latter, then I don't follow.

The flow is as follows:

  client                     server
  ------                     ------
  send request ->
  wait for response          
                             read request
                             process msgfd, allowing only a single fd
                             monitor handles request
                          <- send reply
  handle response            close msgfd if unused
  send next request ->

If the client sends multiple requests at once, it is broken - it must
wait for a "(qemu) " reply before sending another request.

If the client sends multiple fds in a single request, it is broken - no
monitor commands support multiple fds.

If the client is broken and sends multiple fds, we only read the first
one and the kernel frees the others.

If the client sends an fd along with a request which does not require an
fd, we just close that fd after we've processed the request.

If we get a new protocol which allows multiple requests per message or
multiple fds per request, we can easily add a queue then.

Cheers,
Mark.