Re: Re: FreeBSD 5-current client work....

  The issue I'm trying to solve is not finding the kernel sources, it's
  finding the kernel compilation directory, where important header files
  like vnode_if.h and opt_global.h can be found.

Ultimately it would be a good thing if we could make the afs module
independent of kernel options, so the same module could be used with any
kernel, even if that can only be done for the non-debug version.  It would
be even better if we could build the afs module without having a kernel
build directory, just kernel sources.

I don't understand why the FreeBSD client "subclasses the vnode," as you
say.  The FreeBSD client code originated in the NetBSD client code, which is
also the ancestor of the OpenBSD client.  Both Open and Net (which is
defunct now) use a data pointer in the vnode rather than embedding the afs
node in the vnode.  So someone had to put some effort into re-arranging the
code to be as it is now.  I'd like to know why that was done before changing
the 4.x code.

If anyone on this list cares about 4.x, it would be a big help if you could
try out Garrett's patch and see if you can make it work.

  It's clear that the old code really actually wants a mutex and not a
  reader-writer lock in any case.  In 4.x, lockmgr() was all we had.
  Now we have full suite of mutexes, condvars, shared/exclusive locks,
  and semaphores, in addition to the old-style lockmgr() locks.

Here's my understanding of the history.  In the bad old days, the unix
kernel was not re-entrant, except for interrupts.  Kernel code would run
until it slept or until it returned to the user.  As re-entrancy was
gradually introduced to the kernel, the easiest thing was to put in a big
chicken lock (afs_global_lock).  So anything you can do to reduce the
granularity of locking, and in particular switching to mutexes, is a good
thing.  I just don't know how easy it's going to be.

  Ultimately, afs_osi_Alloc() calls AFS_KALLOC() after mangling its
  arguments, which expands into malloc(size, MT_AFS, M_WAITOK) on
  FreeBSD.

That sounds fine.  I agree with you about funky allocators.  I'm sure they
were put in back when kernel allocators weren't very good, and there is no
longer any reason for them in the bsd clients.  I would encourage you to
replace them with the native allocators if you get ambitious.

  I'm guessing that in traditional (4BSD)
  implementations, ``small'' allocations were done in mbufs, ``medium''
  allocations used mbuf clusters, and ``large'' used I/O buffers,
  correct?

My memory is hazy, but I think they were separate so the small allocations
could be cached instead of returned, and the big ones could be returned.