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

[Ken Raeburn]

assar at stacken.kth.se writes:
> Assuming it's not divulging any important secrets, could you tell me
> the $Id$ from the file afssydefs.h.  In my copy of the file the
> following lines have been there since 1.5 (from 1995/12/02):
> 
> #if defined(__NetBSD__)
> #define AFS_SYSCALL 210
> #endif

In the copy of src/domestic/lib/libkafs/afssysdefs.h I've got, there
is no such definition, and the version is 1.2 dated 1995/12/17.
Checking the netbsd-current sources on ftp.netbsd.org yields the same
result.

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

Okay.  I edited my afssysdefs.h and reinstalled libkafs before
configuring.


With the patches I've received (three from assar, one each from map
and lha) and two of my own (lib/acl/Makefile.in INCLUDES, sed command
in xfs/bsd/bin/Makefile.in), I ran autoconf and autoheader, and made
my /sys link invalid (as it had been originally).

Configured in one subdirectory for CNS krb4:

	../configure --prefix=/usr/arla --with-krb4=/usr/kerberos
		--with-sys=/kr/projects/netbsd/NetBSD/src/sys 

Configured in anoter subdirectory for NetBSD-domestic krb4:

	../configure --prefix=/usr/arla
		--with-sys=/kr/projects/netbsd/NetBSD/src/sys 

Both trees built without errors.

I installed the netbsd-domestic version and started it.  After about 4
minutes, with fairly little network traffic having happened, "cd /afs"
(athena.mit.edu's root.afs) works but "ls" or "cd /afs/athena"
doesn't, I get "Device not configured".  Even running arlad in test
mode, I can't get there.

Guessing that maybe the previous crashes or the switch in Kerberos
versions had messed up the cache somehow, I deleted it and tried
again; this time, it all seems to work fine, and I've gotten directory
listings from MIT, CMU, and KTH.

Now both versions of "fs" report a sysname of "i386_nbsd13".

So Assar's patches all seem to be working.  The other patches were for
crashes that only happened after the system had been running a while,
usually while cron jobs of mine were peeking at certain AFS
directories, so I'll have to wait and see.

Just for curiousity I tried a few other "fs" commands (using the Arla
version), and all seemed to work okay except:

    % /usr/arla/bin/fs gcpags
    getcrypt: extraneous arguments ignored
    fs : error Bad address (14) return from pioctl
    %

The first message appears to be because argc should be 1 when gc_cmd
is called with no arguments, and the printed routine name is wrong; I
haven't looked into the second.

Ken