(Illustration by Gaich Muramatsu)
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>Received on 2006-03-04 13:19:13