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 <[EMAIL PROTECTED]>
