>Note that an AFS inode number is not the same as the corresponding
>inode number on the remote disk.  The AFS server does play around with
>inodes in an unethical manner, but that's because of access control
>lists, not namei caching.  The AFS server is not available for NetBSD,
>and it would reportedly be difficult to port because there aren't
>enough spare inode fields in the BSD 4.4 FFS to hold the access
>control list information used by the AFS server.

Now, I don't know a whole lot about AFS internals, so please correct me if
I'm wrong.

The idea of running a AFS server at home between a couple of NetBSD boxes
has interested me for some time (hey, doesn't it interest _everybody_? :-) )

>From looking at things, what everyone is primarily interested in is the
struct dinode, right?  (Since that's what lives on disk).

A glance at afs/auxinode.h would seem to hint that you need 5 extra fields in
the dinode structure:

	di_vicemagic		- long
	di_vicep1		- int
	di_vicep2		- int
	di_vicep3		- int
	di_vicep4		- int

So, what's free in the dinode?

A lot of other AFS ports seem to use di_gen (or similar) for vicemagic.  A
quick grep through the ufs tree doesn't show that it's being used; looks
like it's okay.

There are two longs available in di_spare.  That takes care of vicep1 and
vicep2.

The union holding oldids/inumber doesn't seem to be used by FFS (it's still
used by LFS, but let's pretend we're not going to run LFS underneath AFS).
That's vicep3.

As for the last one .... hmmm.  I'm not quite sure of all the AFS<->FFS
interrelations.  Perhaps di_flags?  (Since chflags wouldn't have a defined
meaning in AFS).  But setting di_flags to weird values might mess up the
interaction with FFS.

Looks like all the interesting stuff with flags happens in ufs_vnops.c.  I
think you could hack this so if i_gen == VICEMAGIC, ignore the flags.  It
would be a grody hack, but I think it would work.

So, does this make sense?  Or did I miss something?

--Ken