This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- From: Thorsten Kukuk <kukuk at suse dot de>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Chuck Lever <chucklever at gmail dot com>, libc-alpha at sourceware dot org, libtirpc List <libtirpc-devel at lists dot sourceforge dot net>
- Date: Sat, 5 Mar 2016 10:51:06 +0100
- Subject: Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- Authentication-results: sourceware.org; auth=none
- References: <20150624124457 dot GA7930 at suse dot de> <879047F3-9559-4D45-839D-F047AB65C7E3 at gmail dot com> <20150625153358 dot GB858 at suse dot de> <6C65D423-D8A4-4E76-825A-850538A23AFF at gmail dot com> <20160304232516 dot 4E8112C3B92 at topped-with-meat dot com>
Hi,
On Fri, Mar 04, Roland McGrath wrote:
> > > src/getrpcent.c: We use the glibc function already if available, don't
> > > know on which OS we compile our own version.
> >
> > According to commit 489912cad88f musl libc does not provide them.
> >
> > AFAICT nothing in libtirpc calls these functions. They are provided only
> > for external library consumers. If these functions dip their hands into
> > the YP maps, then maybe they should be removed from glibc and libtirpc
> > and be provided by libnsl instead.
>
> The existing glibc implementations use the nsswitch mechanism (as IIRC
> these functions do on Solaris). That can't really be implemented outside
> of libc (unless we add a whole new public API for that). It may well be
> that nobody really cares about full nsswitch configurability for getrpc*
> and they could be implemented elsewhere (in the new sunrpc library if files
> only, or in the new YP implementation if files + YP/NIS+).
My first thought was: there is absolute no reason to put
/etc/rpc into LDAP/NIS/ or whatever else, so removing NSS support
and have only a "files" version in libtirpc would be fine with me.
But looking at our customer configurations/feedback, it looks like
quite a lot of companies are still distributiong /etc/rpc via network...
So we should not remove NSS support.
> We certainly
> would prefer to get rid of them from libc altogether along with all sunrpc
> and YP related interfaces. But if what users need is a new implementation
> of exactly the same functionality the old libc implementation had, then
> that might be difficult. Fortunately, getrpc* is about the single least
> troublesome thing in this whole mess, so if it just sticks around in libc
> much longer than the rest, that's not really any burden to us.
Looking at the code, I would let rpc/netdb.h and corresponding functions
stay in glibc.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)