[OpenAFS-devel] FreeBSD 5-current client work....

[Jim Rees]

Excellent!  Thank you very much for tackling this.  I have been working as
time permits on the FreeBSD 5.x client, but as you probably noticed didn't
get very far.

You should join the port-freebsd@openafs.org list, and post there instead of
here, at least until the client is working and commited to cvs.  Feel free
to send diffs directly to me if you want.  If you can clear up the 4.x vs
5.x issue for me (see below) I'll start commiting.

  - It is essential that libafs.ko be compiled using the kernel's actual
  option headers (opt_global.h in particular) and not fake ones.

Agreed, but we need to find a better way.  In particular, I don't understand
"-I/sys/i386/compile/AFS."  Where does that come from?  At least use
@BSD_KERNEL_PATH@ instead of /sys.  See MakefileProto.OBSD.in for an
example.

  - Most of the necessary fixes were simply telling the FreeBSD port to
  use the same serup as OpenBSD.  It will never be possible (or
  sensible) for AFS to ``subclass'' struct vnode in FreeBSD.

But that's not true for 4.x, right?  Your diff changes this for 4.x, and
introduces some other things (like curthread) that make me think it won't
work on 4.x.  I don't have 4.x here to test with.

  In order to do that, while avoiding race conditions, I
  turned afs_global_lock into afs_global_mtx.

Why?  As you found out, this introduces problems.  Why not leave it as-is?

  - It seems as if, with a decent kernel memory allocator, almost all of
  afs_osi_alloc() could be thrown out.

The traditional allocator is the set of osi_Alloc routines in
afs_osi_alloc.c.  These are there because in the old days kernels didn't
have memory allocators at all.

The "new" way is to call afs_osi_Alloc(), which usually turns into the
native kernel allocator for whatever system you're on.  Correct me if I'm
wrong.