> 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.
