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: proposal: nsswitch refactoring


* Carlos O'Donell:

> * Refactor code to make the list of NSS lookups functions static and
>    knowable at compiler time. We don't *need* a dynamic list of them,
>    because the code must know which to call, it's dynamic simple by virtue
>    of the existing design (a bunch of code which calls a function after
>    making some choices).

I'm not sure if this is strictly necessary.

Consider the handling of nip in git/nss/getXXbyYY_r.c.  Maybe it is
possible to retain that processing and just have calls to obtain an
initial nip and clean it afterwards?  Then this could main the
registration with the global configuration object.

I'm not saying that switching to central tables wouldn't be useful.  I
expect it will be.  But maybe it's possible to find a way to implement
the reload protection without that.

> * Refactor code to use a ref-count mechanism like in the resolver
>    configuration case (reusing as much ref-count stuff as possible or
>    generalizing it).

We might just put the whole thing into the same struct.  It will
introduce a tiny additional overhead because an application call
getpwnam locally will now load /etc/resolv.conf as well.  (The reverse
case, an application use libresolv without any NSS functions, is
really limited.)


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