On Thu, Dec 13, 2012 at 02:03:31AM +0100, Laurent Bercot wrote: > > The thread you referenced is all silly; it's a rant about an > > implementation detail (NSS) of glibc that does not even apply to > > uClibc. If you want to lookup hostnames, you use getaddrinfo. > > Whether or not NSS is a glibc implementation detail, getaddrinfo() was > designed to accommodate NSS, and because of that, it is a horrible API
I don't see how getaddrinfo was "designed to accommodate NSS". It's designed to abstract the operation of translating host and service names to addresses from the underlying implementation (DNS). This is a fairly important abstraction, especially with IPv6 in mind; if you application were just sending DNS A requests, it would break when the user needs to switch to IPv6. With proper use of getaddrinfo, you never even allocate any address-family-specific sockaddr structures yourself, and your application works transparently with IPv4, IPv6, and any hypothetical future protocols. > to perform DNS, with focus on details totally irrelevant to DNS and no > way to access and tune important DNS engine knobs. The most obvious flaw > is that it is a blocking, synchronous call that performs network > operations with no way of specifying a timeout. It's only the first one. glibc has a nice alternate version of getaddrinfo for asynchronous use, which can easily be emulated on systems that lack it using threads and getaddrinfo. Given that, on any modern system, thread creation and termination take less time than a DNS lookup, I don't see this as a significant cost. I don't think you can implement a good general-purpose asynchronous lookup interface without threads anyway, unless you're going to require that the caller have a select/poll based event loop and make calls back into the lookup function on each event. If you have a design for one, I'd love to see it... > > Consider a system behind a restrictive firewall with no access to DNS > > except possibly for a local intranet, and minimal outgoing access at > > all. A resolver module that caches results locally and routes unknown > > requests over a special protocol is perfectly reasonable. > > Yes, but DNS proxying should be done by the *resolver program*, not by > the *client library*. Special-purpose resolvers exist ; no system > architecture needs proxying at the client library level. And in any > case, no system architecture can be justification for bad API design. I agree proxying should be done by an external DNS program. NSS is a very bad design. An ongoing issue we're working on addressing in musl is how to support alternate backends for other non-DNS things NSS provides -- mainly the user database -- without ugly hacks like putting them all in the libc. The eventual solution will probably be some sort of proxying daemon that speaks either NSCD protocol or a textual protocol that's nearly identical to the /etc/passwd format. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
