This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc/libtirpc and future of client RPC code
- From: Thorsten Kukuk <kukuk at suse dot de>
- To: libc-alpha at sourceware dot org, libtirpc-devel at lists dot sourceforge dot net
- Date: Thu, 25 Jun 2015 12:14:56 +0200
- Subject: Re: glibc/libtirpc and future of client RPC code
- Authentication-results: sourceware.org; auth=none
- References: <20150624124457 dot GA7930 at suse dot de> <20150625100529 dot GQ17734 at vapier>
On Thu, Jun 25, Mike Frysinger wrote:
> On 24 Jun 2015 14:44, Thorsten Kukuk wrote:
> > that's a mail for RFC, advice, ideas, or however you want to
> > call it.
> > And since it affects glibc and libtirpc, I decided to do a crosspost
> > on both developer mailing lists.
> >
> > Last year I implemented the NIS protocol for IPv6. With libtirpc,
> > this was no problem on server side, ypserv/ypbind are working fine.
> >
> > But now I run into a lot of problems on the client side.
> > In the end, this step is quite easy: link the NIS client code
> > against libtirpc and this is it more or less. The public
> > interfaces of the client code will stay the same, no API or
> > ABI changes. The only difference is, that suddenly all applications
> > using this interfaces can speak with a IPv6 NIS server.
> > But: the NIS client code is part of glibc, which only comes
> > with the IPv4 only SunRPC implementation.
> >
> > So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
> > from glibc needs to be moved somewhere else and somehow we need to
> > be able to disable that code in glibc then, or at least make it
> > runtime only.
>
> pretty sure the --disable-obsolete-rpc flag already accomplishes this. the
> problem is that libtirpc is not a full replacement yet for the API in glibc.
Thanks, I will look at that.
> > Since libtirpc has code calling YP and NIS+ functions, which are
> > currently disabled, moving it to libtirpc would be one choice. But
> > I don't know if we don't run into a license conflict here between the
> > glibc and tirpc licenses. The second disadvantage is that this would
> > mean to touch all applications linked against libnsl and calling
> > yp_*() functions. That's something I want to avoid.
>
> the sunrpc code in glibc should still be under its original license, so i don't
> think moving it over should be a problem.
It's not about the sunrpc code in glibc, it's about the code in
the nis directory of glibc. This code depends on RPC, but needs
to be compiled/linked against TI-RPC, not SunRPC.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)