Re: [RFC PATCH 0/2] Add AF_VSOCK support to getnameinfo(3) and getaddrinfo(3)

[Florian Weimer <fweimer at redhat dot com>]

On 12/05/2016 04:58 PM, Stefan Hajnoczi wrote:
> On Fri, Oct 07, 2016 at 04:02:19PM +0200, Florian Weimer wrote:
> > On 10/06/2016 01:19 PM, Florian Weimer wrote:
> >
> > > > > How do you expect that applications will know that they have to pass
> > > > > AF_VSOCK to getaddrinfo instead of AF_UNSPEC?
> > > >
> > > > For example ncat(1) has --unixsock and --udp command-line options.  A
> > > > --vsock option can be added.  At that point the program knows to use
> > > > AF_VSOCK and the same getaddrinfo(3) code path can be used by TCP, UDP,
> > > > UNIX, and vsock.
> > >
> > > ncat doesn't use getaddrinfo AFAICS, so this isn't going to help it. The
> > > larger nmap codebase has a call to getaddrinfo, but the code leading to
> > > it assumes 16-bit port numbers, so it won't be able to use getaddrinfo
> > > either.
> > >
> > > Do you have a better example?
> >
> > I've looked briefly at nfs-utils.  I don't see how you can patch in AF_VSOCK
> > support using the proposed getaddrinfo support, either.  It seems to do the
> > address and service lookup separately.
>
> There are quite a few code paths in mount.nfs(8), maybe you are looking
> at an unrelated one?  The nfs-utils patch series I've proposed does not
> use service lookup:
>
> https://www.spinics.net/lists/linux-nfs/msg60291.html
>
>   # mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock

Well, that was my point.

You claimed that we need to add this to getaddrinfo to simplify porting 
sockets code to AF_VSOCK.  But based on my analysis of the examples you 
provided, using getaddrinfo would not simplify matters at all or 
introduce bugs (due to truncation of port numbers to 16 bits).

> One of the factors that makes me think glibc should support AF_VSOCK in
> getaddrinfo(3) is that programs that pass around struct addrinfo are
> hard to modify.  Only glibc can allocate struct addrinfo because only
> glibc knows how to free addrinfo in freeaddrinfo().

That's certainly valid.  But then, I don't see any programs which use 
getaddrinfo and could transparently upgrade to AF_VSOCK anyway.

Thanks,
Florian