But that is not really true, the inode we return as a in the coda_open
  reply is not a Coda inode, but the device/inode pair of the container
  file, so it really is a true ino_t.

I have changed NetBSD-current back to ino_t.  But this means an ABI
change in the kernel/user protocol.  My inclination is to say "oh
well, you really have to compile venus on the same system you run it
on", but then I wonder if we should be bumping the number.  Presumably
the Linux ABI is different from the NetBSD ABI anyway - I wouldn't
expect to be able to run Linux venus on NetBSD.  (Given the source is
available there'd be no point anyway, and mount calls are different,
etc.)

I have been having a lot of crashes on recent NetBSD with an old
venus, in coda_readlink.  I wonder if this is related to the ino_t
changes (venus compiled with old ino_t definition, kernel with wrong
type in coda.h, so they mostly match).  But a system with a recent
kernel still crashes.

NetBSD's coda.h  has:

static inline ino_t coda_f2i(CodaFid *fid)
{
        if (!fid) return 0;
        return (fid->opaque[1] + (fid->opaque[2]<<10) + (fid->opaque[3]<<20));
}

This will not necessarily produce unique inode numbers, but one can't
collapse the opaque fields down to inodes anyway.  I presume that's ok
and these are just to provide an inode to user space.  But perhaps we
shoudl do better with the 64-bit space on NetBSD.

-- 
        Greg Troxel <gdt_at_ir.bbn.com>