Date: Sun, 15 Jul 2001 17:18:54 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Bernd Walter <ticso@mail.cicely.de> Cc: Hajimu UMEMOTO <ume@mahoroba.org>, freebsd-net@FreeBSD.ORG Subject: Re: how to get AF_LOCAL from getaddrinfo() Message-ID: <200107151718.aa17383@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sat, 14 Jul 2001 18:44:27 %2B0200." <20010714184427.C23031@cicely20.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010714184427.C23031@cicely20.cicely.de>, Bernd Walter writes: >> Our getaddrinfo(3) doesn't support AF_UNIX. > >Arg - I looked into src/contrib/bin/lib/irs/getaddrinfo.c >The one in libc is different... I'd very much like to see PF_LOCAL support added to our getaddrinfo() and getnameinfo(). I know that PF_LOCAL sockets have semantics that are quite different to other protocol families, so the goal of protocol-independent translation is not really met. However supporting this will still result in simpler code within many programs. Is there any standard that defines how getaddrinfo() should deal with PF_LOCAL addreses? I guess we could do something such as the following, but it would make sense to stick to the same semantics as any other implementations that might exist: getaddrinfo: nodename NULL (maybe allow "localhost" or just ignore?) servname NUL-terminated sun_path hints: ai_flags AI_PASSIVE, AI_NUMERICHOST ignored AI_CANONNAME must not be specified ai_family must be PF_LOCAL ai_socktype SOCK_STREAM or SOCK_DGRAM ai_protocol must be 0 ai_addrlen must be 0 ai_canonname must be NULL ai_addr must be NULL ai_next must be NULL getnameinfo: host, hostlen maybe require NULL, or store "localhost"? serv, servlen store NUL-terminated sun_path flags ignore NI_NOFQDN, NI_NUMERICHOST, NI_NAMEREQD, NI_NUMERICSERV, NI_DGRAM These look quite easy to implement, since the code can just check hints->ai_family (for getnameinfo, sa->sa_family) to determine if the request is for a PF_LOCAL address. Obviously, to create listening PF_LOCAL sockets, the caller still has to do the unlink (and umask if desired). Any comments or suggestions, or should I just try this and post proposed patches? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200107151718.aa17383>