I don't see it as an ABI change, since venus correctly uses ino_t. It
  was an incorrect kernel-side change from ino_t to uint32_t that broke
  things.

What I meant was  that when NetBSD changed ino_t from 32 to 64 bits,
the ABI of the venus/kernel interface changed, so that venii compiled
with old headers will no longer run on new kernels.  The right thing
to do would have been to version the change so old venii ran, and used
a new opcode for the 64 bit ino_t version, but really there's not a
huge point in being able to run old venus binaries.

My readlink problem is a kernel page fault.  The asm looked like a
null pointer used to get a structure member.  Have traces, will look
at ask when I have a chance.

  But back to the coda_f2i function. This one should really be kept in sync
  between userspace and kernel space because of the way directory contents
  are passed down to the kernel. Venus creates BSD-style directory entries
  with (name,ino) pairs, and uses its own copy of coda_f2i to map from
  fids to inode numbers. Now the kernel should use the same function
  otherwise we end up with different inode numbers identifying the same
  object.


Ah, another reason to require the kernel .h to define this as an
inline and have venus use the kernel's definition!

  This is really the only place where venus knows about Coda inodes, and
  it would be a lot cleaner if it just sent down (name,fid) tuples for the
  directory entries and left all the fid->ino_t mapping up to the kernel.

sure, but that's a bigger change.

So I should change f2i in the NetBSD kernel to match the venus code?

I wonder if this is causing trouble, perhaps combined with inadequate
error checking.

-- 
        Greg Troxel <gdt_at_ir.bbn.com>