Re: [Qemu-devel] Re: Planning for 0.13

[Jamie Lokier <jamie@shareable.org>]

Michael S. Tsirkin wrote:
> On Wed, Jan 06, 2010 at 08:48:16PM +0100, Paolo Bonzini wrote:
> > On 01/06/2010 04:10 PM, Anthony Liguori wrote:
> >> We have ones that require read/write, ones that require send/recv, and
> >> ones that require vhost interaction.  Really, the first two are the same
> >> but the distinction is necessary for Windows.
> >
> > Not necessarily, you can open sockets on Windows so that they support  
> > read/write.  Just create it with
> >
> >   fh = WSASocket (domain, type, protocol, NULL, 0, 0);
> >
> > instead of socket.  Since Windows already has enough problems passing  
> > file descriptors to processes, imposing the above on an external  
> > management interface is not a huge chore.

I think socket() is equivalent to that WSASocket() on all modern
Windows versions (since Windows 2000 or so; actually the Windows NT
line and Winsock 2), so there isn't any need for WSASocket.

Passing socket file descriptors isn't very hard (again, the NT line),
but it's different from unix obviously.

On unix you can use a unix domain datagram socket if you're just
communicating with a local process, so recv/send can always be used.

On Windows, you have to use something else for local process
communications (loopback TCP sockets can be used but are sometimes
blocked by annoying software).  A smart thing to do would be detect
the type of handle received, and use the appropriate way of talking to
it, but since you need to receive a string to receive a handle anyway,
it's trivial to include an option with the string saying how to talk to it.

> For linux read/write often isn't a good idea :) E.g. for packet
> sockets you really need to use sendmsg and set msg_name with the
> proper protocol.  You also must use recvmsg and set MSG_TRUNC
> otherwise packets can get truncatred silently.

On packet sockets, connect() + write() should be equivalent to sendmsg
to the connected addresses.  If not it's a bit of a kernel bug.  Is it?
Agreed about recvmsg and MSG_TRUNC though.

But anyway, in what situation would you not use recv/send (except
Windows local IPC)?  And if there is one, is there ever a situation
where fstat() cannot be used by qemu to decide what to use?  If packet
sockets needs sendmsg with msg_name, it could call getpeername and
always use that :-)

-- Jamie