proposal: nsswitch refactoring

[DJ Delorie]

Red Hat has had a long-standing request to make nsswitch.conf
reloadable.  It's come up again recently, so I'm looking to see what
it would take.

After discussing this with Carlos a bit, I've broken the task into
three phases.  I'd like some feedback on what the community (i.e. us)
thinks about my general direction on this, so I don't waste a lot of
time.

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.

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.

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.

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.

Note: I had considered at one point allowing nsswitch to choose
handlers based on the query string itself, but feedback seems to be
that *that* kind of logic should be, itself, in a shared object
handler.

I don't know what other kinds of "smarts" should be in nsswitch.conf
itself, but I'm trying to consider future unknown additions :-)

Thoughts?