The kernel headers need some real cleaning either way. I was thinking of
  having a uniform coda.h that would be identical across all platforms
  without any platform specific parts and a separate coda_types.h which
  defines the correct types depending on each cpu/OS.

  This avoids the #ifdef hell that we currently have in coda.h while in
  userspace we can use configure to detect all the right datatypes. We
  just can't expect our kernels to require autoconf.

Just to make my long-ranted point again: the kernel header for coda.h
is the definition of the kernel interface, and this should be
maintained with (and compiled with) the kernel code, and installed
under /usr/include someplace _by the kernel_.  Coda userland should
then use it.  Having a .h which defines the kernel interface in a
package maintained separately from the kernel code is madness, and
we've only gotten away with it so far because it's so static in
practice.

  I do believe that uint32_t and int32_t are pretty much universal, except
  on very old Linux systems. There are a couple of RH-5.1 boxes in our lab
  that definitely do not define these.

sure, and IMHO it's past time to declare sujch systems ancient, and
have some compat decls if really needed.

  But there are probably more subtle differences involving dev_t,
  ino_t, off_t and size_t.  These can easily be different between what
  we see in the kernel and what libc provides in userspace.

huh?  dev_t etc. are defined by the kernel sources, and this include
file should be installed in /usr/include/sys someplace (sys/types.h on
BSD), and libc compiled against this.  Having libc use different types
for fundamental kernel interface types than the actual kernel code
uses seems pretty crazy to me.  Does Linux really have separate
parallel worlds for libc and kernel that have to be kept in sync for
things to work?  Sorry if I'm sounding cranky but it seems like there
are some underlying consistency problems bigger than coda.

int on some systems could be 64 bits.  It's 32 on common 64-bit
platforms, but no language rule requires that.  So let's not rely on
int being 32 bits in header files - if we mean 32-bit fixed width,
let's say int32_t.  I think it's a good idea to enable 32-bit venus to
work on 64-bit kernels, as a stopgap measure until all the coda code
is 64-bit clean.   Strictly speaking this could be done by having a
32-bit emulation for the venus device, but it's far easier to have one
fixed-width interface.

-- 
        Greg Troxel <gdt_at_ir.bbn.com>