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: Intention of "headers-not-in-tirpc"?


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)


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