Sure, this whole thing happens to come in when I'm away ...

I occasionally try to get some work done on a server-side port of
AFS for NetBSD, so let me throw my $0.02 in ...

>JS> It's not just in-kernel; AFS uses some of these fields these show up
>JS> on-disk as well, at least in AFS volumes on the server. (newer
>JS> versions may do it differently).  jtk points out there was no AFS
>JS> server-side release for NetBSD; i don't know if anyone ever built one
>JS> `unofficially'.
>JS> Maybe breaking AFS server compatibility is the right thing, but we
>JS> should be aware we're doing that, and/or make it an option.
>
>I know of no AFS file servers on NetBSD.  As far as Transarc AFS server
>code is concerned, it doesn't really matter if you use all but one of
>the spares for something else.  There aren't enough spare bits there
>right now, so a server implementation would have to use an alternate
>method involving another place to store most of the extra details (such
>an implementation is used on AIX's JFS, so there's plenty of code to
>borrow).

When I last looked at that, I was told that the JFS stuff was seriously
bit-rotted.  I have no idea if that's the case.  Buuutttt ... I _do_
think there's enough room.

There are nominally 5 32-bit fields needed.  _However_, one of them is
a magic number, and technically doesn't need to be 32 bits.  We could get
away with just a bit in di_flags (and if I ever get anywhere on my port,
I'll formally request a bit to be reserved .... but that's in the
future :-) ).  There's a macro in auxinode.h called IS_VICEMAGIC could
just be modified to check for a set bit instead of a complete magic
number.  There's a few spots that will need to be fixed up to not check
the vicemagic field directly, but that's easy to solve.

Now we're down to 4 32-bit fields.  We can easily use two in di_spare[].
That leaves 2.  One can also be used in di_gen (that's done on other
ports as well).  Which leaves us with one.

A quick glance at the filesystem code leads me to believe that one
can use the oldids[] field.  AFAIK those fields are only touched if
the filesystem is not a BSD 4.4 filesystem.

So, I think this is solvable.  Anyone have any other comments?  Am I
wrong?

BTW, John ... I understand y'all have some patches based on AFS 3.3a.  If
you could make that available on the source-contrib area, I'd appreciate
it :-)

--Ken