On Wed, Jan 06, 2010 at 11:00:11PM +0000, Jamie Lokier wrote: > 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?
No. One of the fields in the address is protocol. We need to look at the packet to figure it out, so it can not be set per socket. > 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 If qemu has special code for e.g. packet sockets, I do not see any advantage in moving setup out of qemu. It's only generic stuff that makes sense to use helpers for. -- MST
