This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH 3/4][BZ 17083] NSS: Introduce gethostbyname5_r function


On 09/12/2017 12:44 PM, Łukasz Stelmach wrote:
> Dnia 12 września 2017 12:03:00 CEST, Florian Weimer <fweimer@redhat.com> napisał(a):
>> On 09/05/2017 06:05 PM, Łukasz Stelmach wrote:
>>> Add af (address family) to the list of arguments of gethostbyname4_r
>>> function in files, dns, nis and nisplus module and rename the
>> function to
>>> gethostbyname5_r. Pass the af value to the underlying parsing
>> functions.
>>> Define gethostbyname4_r as a wrapper for the former passing af set
>>> to AF_UNSPEC.
>>
>> I'd prefer if we have a single ultimate name resolution function,
>> instead of doing function 5 now, and function 6 later, when we have
>> dealt with the malloc matters.
> 
> This sounds like a major debate. Do you know who's in charge in this parts of glibc?

It's a community project.  We don't have strong component ownership.  I
have taken care of networking-related matters for some time now.

>> One way to deal with the dlmopen/static dlopen issue would be to define
>> a deallocation function which goes with the 5 function.  If this
>> function called free, it would automatically end up at the right
>> definition.
> 
> This means almost nothing to me (-; which means, probably I am not the right guy to do it. 

We currently pass a fixed-size buffer into the NSS service module.  The
NSS service module can fail with
NSS_STATUS_TRYAGAIN/NETDB_INTERNAL/ERANGE to indicate that the buffer is
too small.  The caller is supposed to try again with a larger buffer.

This is very inefficient.  It can result in a large number of DNS
queries if there are many addresses (A/AAAA over UDP, then over TCP).

We could avoid this if the NSS service module allocates space for the
result because it knows the required size.  But the module could use a
different malloc than the main program (like Windows DLLs, but for GNU,
this is a special case which does not apply to regular DSO usage).
There are two ways to fix this: The NSS module could provide a
deallocation function, or we could add a mechanism to the dynamic linker
that ensures the mallocs always match.  The second approach is quite
hard to implement.  The first approach has other benefits (e.g., the
service module could return a pointer into a cache and use reference
counting instead of direct malloc/free to manage the memory).

I don't see your name in the maintainers list on the wiki.  Since your
current patches already are substantial contribution, we need to discuss
the matter of copyright assignment:

https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment

I suggest you contact the FSF to eliminate that roadblock before working
on these patches further.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]