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"?


Don't read too much into the existing state of the code.  There hasn't
been much use of the (default) --disable-obsolete-rpc configuration,
and the code for it was all written a few years ago when the state of
TI-RPC was different from what it is today.  

Now we are finally getting serious about the effort with active
coordination between TI-RPC maintainers and glibc maintainers (which
never really happened before, unfortunately).  So we will gladly
reorganize things on the libc side however makes sense for both a
smooth transition and reasonable maintenance burdens throughout.

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.

As to rpc/netdb.h in particular, I have a few thoughts that might
help.

The stub rpc/netdb.h (resolv/rpc/netdb.h) exists for configurations
that do not include sunrpc at all (and never have, so they don't have
any ABI compatibility for it either).  (The only such configuration
supported today is arm-nacl.)  Nobody thought about how it would
interact with --disable-obsolete-rpc for Linux or Hurd configurations.

The only reason the stub is needed in any configuration is because
libc's netdb.h (resolv/netdb.h) does #include <rpc/netdb.h> (when not
in a strict POSIX mode).  I originally did that way back when (1995)
because, at the time, the <netdb.h> from BIND 4.9.3 included the
declarations of 'struct rpcent' and friends (under '#ifdef sun',
believe it or not), and I think the SunOS 4 (aka Solaris 1) version
had them too.  However, according to documentation I can find, as far
back as Solaris 7 (1998) and probably earlier, the documented header
for these things is <rpc/rpcent.h>.  That's what the BSDs have today,
and their <netdb.h> does not declare any rpcent stuff.

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.

This would be an API change that might well break some packages,
albeit with the trivial fix of adding '#include <rpc/rpcent.h>' (but
needing configury to keep building on old glibc systems that don't
have that file).  So we'd need to get thorough consensus from the
glibc community, and consensus might well be to do it as a staged
deprecation rather than fixing <netdb.h> outright in one release cycle.
(Personally, I'm fine with changing this without advance notice.)

There's still the separate question about NSS support for rpcent
functions.  But we can address that after cleaning up the <netdb.h>
situation.


Thanks,
Roland


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