some tasks for suitably interested hackers
Some brief tasks that people might be interested in taking on. These
are fairly quick things, that require only a little investigation.
All of these are from an internal hurd problems list, and some of them
are sufficiently old that the bugs might have been fixed but the
problems entries not deleted.
It's useful if you just say "I checked and the bug is still there"
even if you aren't interested in or able to fix it.
Anyone who has done the relevant investigation can send mail to me
detailing the results.
* Fix emacs/src/unexelf.c to deal with occasional lack of mmap
When this problem was noted, emacs's unexelf.c assumed that mmap
either always exists or never exists. If the autoconf test for
mmap succeeded, then unexec would assume that mmap would work in
unexelf.c, and fail if it didn't. We noticed this problem in
building emacs on an NFS-mounted partition (because NFS doesn't
support mmap right now). The fix would consist of having unexelf.c
tolerate an error from its mmap call, and in that case fall back to
the non-mmap code.
* It would be nice if someone could check profiling on the current
libc. Last time I checked, the call counts worked, but the CPU
usage profiling did not.
* the reboot() call needs to be declared in some header file, and at
some point it was not.
* I have a note about "extra commas in enums in socket.h and
errnos.h" (in libc).
* We have a note that emacs, on standalone system, with no
nsswitch.conf, crashes. "Standalone" here means, I think, that
there is no translator at all on /servers/socket/2. It should be
tested both with no translator on /servers/socket/2, and with a
loopback-only translator there.
* It would be nice if someone could test out fifos (named pipes) to
verify that they work right.
* There is an nfsd in the Hurd right now; it would be nice to see
someone begin using it and report bugs back. It is surely quite
buggy.
* The talk/talkd programs once were reported not to work; it would be
nice to find out if that's still true.
* We have a report that telnetd doesn't fill in the utmp host field
correctly (what you see with the `who' and `w' commands). Is that
still true?
Reply to: