This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc/libtirpc and future of client RPC code


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]