On Fri, Sep 30, 2016 at 12:10:40PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 29, 2016 at 03:25:55PM +0200, Florian Weimer wrote:
> > * Stefan Hajnoczi:
> > 
> > > Many existing programs use getnameinfo(3) and getaddrinfo(3).
> > > Porting programs to support AF_VSOCK is easy if the library
> > > functions can handle this address family.  Without support in glibc
> > > each program needs to duplicate address parsing code and it becomes
> > > harder to port programs.
> > 
> > What has changed since the previous discussion?
> > 
> >   <https://sourceware.org/ml/libc-help/2015-08/msg00004.html>
> > 
> > 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.
> 
> The AF_UNSPEC approach where getaddrinfo(3) parses an arbitrary string
> and figures out the address family can't be supported for the security
> reasons you explained previously.  But the other getnameinfo(3) and
> getaddrinfo(3) use cases still make sense and simplify porting existing
> applications to AF_VSOCK.

Hi Florian,
Did this explanation make sense?  There are many applications that know
the address family but still want to use getaddrinfo(3) to construct a
sockaddr.

> One note about the previous discussion: I had proposed a [vsock:<cid>]
> syntax for the host.  It's not implement in this patch but I will do it
> for the next revision because it fits better into IPv4/IPv6 and URL
> parsing.

Looking into this more the [vsock:<cid>] style quoting is appropriate
for URIs but not for getnameinfo(3) where raw IPv6 are also produced
instead of block quoted addresses.  So I don't think it is necessary the
current formatting.

Stefan