Re: proposal: nsswitch refactoring

[Carlos O'Donell <codonell at redhat dot com>]

On 3/18/19 7:57 PM, DJ Delorie wrote:
> 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.

As Florian points out the binding to the service API is lazy, and worse
the list is not static, it's computed by the calling function.

It seems like the refactoring could take two distinct approaches:

* 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).

* 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).

* Implement the reloading.

After these two things are done (a lot of work) we'll be in a very good
position to review future work against the implementation.

> 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.

This need not be a "third phase", but an entirely distinct project and
discussion around the extension of the nsswitch.conf language to support
various use cases.

--
Cheers,
Carlos.