history of nsswitch internals...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

history of nsswitch internals...

DJ Delorie-2

So I'm looking at the hash[*] of function pointers we use in
nsswitch.c.  There's one hash per database (pwd, grp, hosts, etc),
which makes sense as the function names include the database name so
there's no overlap anyway.  But I'm working on migrating all the
must-be-persistent data out of the might-be-unloaded (tbd) data, and
this is one of them.  A hash of known function pointers in a given app
is persistent (i.e. we don't unload nss modules, so unchanging once
loaded).

My question here is: Has anyone contemplated the performance
ramifications of using a single central hash?  I looked at a
hash-per-library but if you build statically there is no "library" to
associate the hash with.

Moving this hash to a single central (static, persistent) hash should
simplify maintenance of that hash and its memory, instead of having it
spread across many per-service structures.


[*] really a red-black tree, but "hash" is shorter
Reply | Threaded
Open this post in threaded view
|

Re: history of nsswitch internals...

DJ Delorie-2
DJ Delorie <[hidden email]> writes:
> Moving this hash to a single central (static, persistent) hash should
> simplify maintenance of that hash and its memory, instead of having it
> spread across many per-service structures.

Caveat: found out the hard way that the current model "happens to"
enforce the library search order, by simply starting with an empty hash
for each service...  and the hashed function doesn't include the dll
name, despite the functions *in* the dlls including them.  Sigh.