v2 [PATCH 4/4] nsswitch: use new internal API

[DJ Delorie]

"Carlos O'Donell" <carlos@redhat.com> writes:
> The system works perfectly fine, but in the tests I ran the /etc/nsswitch.conf
> doesn't reload.

Sigh, I missed one or two spots... :-P

v3 to follow.

> (1) Test covering changing data after reload for host interfaces.
>
> * New container test case that has 2 NSS services for hosts providing
>   different data.
> * Start the test with one set of data and call:
>   * gethostbyname
>   * gethostbyname_r
>   * gethostbyname2
>   * gethostbyname2_r

These all just call getXXbyYY or getXXbyYY_r, and getXXbyYY just calls
getXXbyYY_r, so... I just tested the first and last of these.

>   * gethostbyaddr
>   * getaddrinfo
>   * getnameinfo

Done.

> (2) Test covering non-changing reload for setent/getent/endent for hosts.

Included in the one test for simplicity - setting up the two backend
providers is a lot of lines of data, relative to the actual test code.

> * Start the test with one set of data and call:
>   * setent
>   * getent ...
> * Change the file mid enumeration.
> * More of:
>   * getent ...
>   * endent

Note that the set/get/end functions, even the foo_r() variants, are NOT
recursive-safe.  Reentrant versions still use a single "where in the
list" pointer.  So I overlapped set/get/end with a getXXbyYY call of the
same database instead.

> * Verify results match first service data (service not changed and cached
>   until endent).
> * Start a second iteration of:
>   * setent
>   * getent
>   * endent
> * Verify results match second service data.

Done.

> That should be enough to validate the reloading.

The only path left untested, that I know of, is in gethostbyname4.
Adding that to the nss test backends is more work than it's worth for
this one test, and it uses one of two paths so you can't test them both
at the same time anyway.