Re: proposal: nsswitch refactoring

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

* DJ Delorie:

>> We already do this for the resolver configuration.  We could probably
>> reuse the same mechanism, and even the same data structure.
>
> Thanks, I'll look at it.

It's struct resolv_conf, by the way.  struct resolv_context is the
temporary thing.  Allocating it prevents the struct resolv_conf object
from going away, among other things.

>> 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?
>
> This doesn't include the shared objects like nss_files, nss_ldap, etc.
> Just the core code that calls them all.  I figure the arguments would
> need to be stored in a struct, possibly with some other stateful
> information.  Like this pseudo-code:
>
> static int
> my_so_caller (nss_handler *shared_object, my_data *data)
> {
>   /* call the shared_object's functions, passing my_data */
> }
>
> int
> my_api_handler (arg1, arg2, arg3)
> {
>   struct { ... } my_data;
>   my_data.arg1 = arg1;
>   ...
>   nss_logic_handler (NSS_PWNAM, my_so_caller, &my_data);
>   return my_data.rv;
> }
>
> This means that none of the individual API functions need to have code
> to do the logic of nsswitch.conf.
>
> Alternately, the core logic could be a stateful machine:
>
> int
> my_api_handler (arg1, arg2, arg3)
> {
>   nss_logic_state state;
>   nss_logic_initialize (NSS_PWNAM, &state);
>
>   while (nss_logic_handler (&state))
>     state->rv = state->shared_object->do_something (arg1, arg2, arg3);
>
>   return nss_logic_finalize (&state);
> }

We use the second approach today, I think, and nss_logic_handler is
called nss_next_action.