Re: proposal: nsswitch refactoring

[Florian Weimer <fw at deneb dot enyo dot de>]

* DJ Delorie:

> First, the data relating to the various shared objects that implement
> the name services (libnss_foo.so) needs to be split out of the data
> specific to nsswitch.conf's layout.  Why?  Because we still never
> unload shared objects, so that data is effectively "write once" and
> should never change.  Separating it from the changable data makes
> sense.

Right, unloading already-loaded modules would be the wrong thing to do
because dlclose could be problematic for NSS service modules.

We currently bind lookup functions lazily, so the module data is not
entirely write-once, more like a collection of ivars (called SyncVar
in Concurrent ML, basically futures without blocking).

One tricky aspect about the current framework is that the generic NSS
code does not know which lookup functions exist.  This is handled by
specific lookup implementations.  (For example, only the getaddrinfo
implementation and some of the NSS modules know about
“gethostbyname4_r” lookup functions, the rest of glibc does not care.)
We should probably change that because having a static list of
potentially available functions simplifies memory management.

> Second, the nsswitch-specific data should be "compartmentalized"
> somehow, so that we can reference count it, set aside the "old" copy
> when we load a "new" copy, and clean it up after we know that there
> are no further users of that data.

We already do this for the resolver configuration.  We could probably
reuse the same mechanism, and even the same data structure.

> There are two schools of thought here - one memory chunk with all the
> data in it, or spread out data with careful management of it.  One
> chunk is easier to free up (just call free()) but has some overhead in
> packing the data into it.  Spread out data is easier to understand and
> manipulate, but you have to be more careful about cleanup.

I don't think there is much choice unless we statically encode the set
of supported lookup functions.

> The third phase is to consider expanding the syntax and functionality
> of nsswitch.conf.  My "vision" on this is to compile the nsswitch
> logic into a tiny p-code, and centralize running it.  That way, an API
> (like getpwnam()) need only set up some data (query arguments, etc),
> and pass said data and a callback function to this central logic
> handler, which calls the callback when it decides which shared object
> needs to be queried next.  This p-code could include new actions like
> two-way branching, more interesting error handlers, etc.

Which aspect are you referring to?  The handling of struct pwd, struct
hostend, etc., including parsing file data?  Or forwarding a lookup
operation from a function such as getpwnam to an NSS module function
like _nss_files_getpwnam_r?

We currently generate code for this in glibc at compile time, via the
preprocessor, for both.  (But nscd has a separate mechanism for struct
marshalling.)  This seems independent from the other changes.