12-28 snapshot on netbsd1.3H - much better luck this time

[Ken Raeburn]

assar at stacken.kth.se writes:

> > ../../arlad/arla.c:874: Undefined symbol `_krb_get_err_text' referenced from text segment
> 
> Try the appended patches and tell us if it works for you.

Will do.

> > Is a delay needed after arlad forks off before accessing /afs?
> 
> Currently, yes.  It shouldn't be.  Try running arlad with
> `--fork-late' and tell us if that solves the problem.  (It should
> probably be made the default behaviour.)

Perhaps.  Or accesses to /afs could be made to cause interruptible
delays until it's initialized.  That's probably harder, but would
permit other system startup tasks that don't depend on AFS to run
concurrently with the arla initialization.

> > Apparently the NetBSD libkafs k_hasafs() simply doesn't think I have
> > AFS.  It wasn't compiled to know about any AFS syscalls.  I suppose
> > I'll fetch the CMU version, or kth-krb.  (A third version of krb4 for
> > my system?! *sigh*)
> 
> Can you find out (by running ktrace or reading the source) what
> syscall the NetBSD libkafs is trying to use?  The xfs module will
> install itself as syscall 210 if that's available and otherwise as the
> first free slot reserved for LKMs.

The source has multiple "#ifdef FOO / try syscall FOO / #endif"
blocks, but from my disassembly, it appears that none are used in my
installed copy.  So the code is merely fiddling with signal handlers
and returning a failure indication.  My guess is that the macros it
tests are intended to be hard-coded numbers, but I don't think they
need to be.  I'll look into it further.

If the number 210 is magic for Transarc AFS on NetBSD, that would
explain why the Transarc binaries I got from MIT seemed to work.  But
"fs sysname" reported "_nbsd13", which doesn't seem right.  Is this
all as expected?

Ken