Re: patches for rpc utility programs
> I'm still waiting to hear from Roland about the rpc_svc() glibc bug, but in
> the meantime I'll try to start submitting patches...
I am going try to address this for glibc-2.2, but I may not get anything
for it into 2.1 at this point. I think you can work around the problem by
using `setrlimit (RLIMIT_OFILE, ...)' to set the maximum number of open
file descriptors to something finite (the default is RLIM_INFINITY, i.e.
0x7fffffff, and the sunrpc code tries to use this to allocate a table).
Unfortunately those limits do not propagate at all, so this has to be a
direct setrlimit call done first thing in the program using the rpc svc stuff.
> I've grabbed the source for the debian netbase-3.16 package to compile
> rpcgen, rpcinfo and portmap. But who is supposed to get theese patches?
It is always right to post them here first for our opinions about what you
have done to accomodate the Hurd. When we like the patches, then they
should go to the debian maintainer and/or upstream maintainers. When it is
questionable or you have trouble talking to other debian maintainers, then
Marcus is the person who decides how to deal with it.
> The rpcgen patch is a straightforward replace-MAXPATHLEN-with-malloc thingie.
> This should be submitted to the upstream maintainer.
Please do.
> from_local() uses ioctl() to get all active network interfaces. Hurd has no
> devices to support this. I want a generic, portable libc function that
> returns a list of interfaces. Somebody add that to the glibc wishlist?
The right interface to be using is if_nameindex et al from <net/if.h>.
This interface works on current glibc's on Linux; for the Hurd, the
functions are there but always just fail with ENOSYS, so it is reasonable
to start using them now and just be graceful about that failure mode. I've
just implemented those functions for glibc-2.2, but that code is not likely
to go into glibc-2.1, and things might change before glibc-2.2 comes out.
However, that is a standardized interface for this very thing, and most
definitely the right source interface to be using whenever possible.
> Anyway, I have avoided from_local() by turning off HOSTS_ACCESS and turning
> on LOOPBACK_SETUNSET (set and unset only from loopback-devices.)
> I can rewrite the relevant parts of pmap_check.c to enable HOSTS_ACCESS
> (libwrap) without using from_local(). However this will be incompatible
> with the linux behavore, as you will have to add local address(es) to
> /etc/hosts.allow. Any opinions?
In any case like this, where the issue is a feature the Hurd now lacks but
clearly ought to have, then I would always encourage the least modification
to the other party's sources. Usually we already the have source code
interfaces, they're just stubs that always fail (which is specially
detected as "not present" by autoconf checks). So, the best modifications
to make are usually the ones that just make the program deal more
gracefully with failures from such functions, and/or use compile-time
autoconf checks--but runtime checks are better for this, since then we can
drop in new shared libraries in the future and have these programs'
existing binaries just start working better.
> The HURD does have strerror() but not sys_errlist/sys_nerr, so obviosly we
> don't want strerror.o.
Indeed. Anything ought to have the standard autoconf check for this and
use strerror if it exists, period.
> The changes to portmap.c should be ok, they're there to supply correct
> information to the next person debugging this program. These should be
> submitted to the upstream maintainer.
Yup. Ya ain't got to ask us about stuff like that. Just tell the upstream
maintainer he's got obvious trivial bugs.
Reply to: