This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Intention of "headers-not-in-tirpc"?
- From: Thorsten Kukuk <kukuk at suse dot de>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 19 Mar 2016 13:31:37 +0100
- Subject: Re: Intention of "headers-not-in-tirpc"?
- Authentication-results: sourceware.org; auth=none
- References: <20160317194236 dot GA16154 at suse dot de> <20160318215347 dot B4A732C3C61 at topped-with-meat dot com>
On Fri, Mar 18, Roland McGrath wrote:
> I think we should just start from scratch with working out a
> "requirements" list. That is, compared to stock glibc trunk today
> configured with --enable-obsolete-rpc, exactly how do we want things
> to be different in the end state. That includes which things libc
> should install and which things TI-RPC should install, and so forth.
> Once we've reached consensus across both projects about that, then
> we can dig into the implementation details of the libc build.
I think glibc should install as less as possible. In the end, I think
it should only provide this functions, which requires NSS:
getrpcbyname.c, getrpcbyname_r.c, getrpcbynumber.c, getrpcbynumber_r.c,
getrpcent.c, getrpcent_r.c
Since this is code, which only includes other glibc functions, but
does not contain any RPC releated, and are all combined together in
a single header file (rpc/netdb.h), I don't see there a real issue
to seperate them.
A bigger problem are the publickey functions:
netname.c and publickey.c
Here, NSS support is required for NIS+, I'm not sure about NFS.
NIS+ is dead and the current TIRPC functions, which only use local
files, seems to work for everybody, so maybe this ones and the publickey
entry in /etc/nsswitch.conf could be removed. And since the prototypes
are spread over different header files, it would be difficult to let
them in glibc.
Third difference are the rpcsvc/*.x files. tirpc does not have them.
But all projects I'm are of, ship their own version anyways. If really
somebody needs one, we can add them to tirpc.
> As to rpc/netdb.h in particular, I have a few thoughts that might
> help.
[...]
> So I propose we change the glibc API to follow suit. That is, make
> <netdb.h> stop including <rpc/netdb.h> and rename <rpc/netdb.h> to
> <rpc/rpcent.h>. (We might leave <rpc/netdb.h> around as a wrapper
> that gives a #warning to prefer <rpc/rpcent.h> instead if that seems
> useful.) Then it becomes straightforward that a glibc configuration
> that supports the old sunrpc API (like today's libc configured with
> --enable-obsolete-rpc) installs <rpc/rpcent.h>, while a glibc
> configuration that does not support the sunrpc API (like the arm-nacl
> configuration, or other builds with --disable-obsolete-rpc or a future
> equivalent) does not install any <rpc/*> headers at all.
Hm, I'm not really sure if I like this. The needed changes to the
applications are much bigger, since you always have to introduce
a configure check. So no quick workaround.
I would propose the following:
- Don't include rpc/netdb.h from <netdb.h>
- glibc stays with rpc/netdb.h as today with --disable-obsolete-rpc
- tirpc <rpc/rpcent.h> includes <rpc/netdb.h> on glibc systems, else
it will provide the prototypes for rpcent itself.
I think that's the less painful solution for everybody and needs
only a small amount of code changes.
> There's still the separate question about NSS support for rpcent
> functions. But we can address that after cleaning up the <netdb.h>
> situation.
I think NSS support for rpcent and <netdb.h> belong together. If
we remove rpcent* support from glibc, we don't need a rpc/netdb.h anymore
at all and should not include that from <netdb.h>.
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)