Coda File System

Re: 64-bit issues

From: Greg Troxel <>
Date: 30 Jul 2004 10:35:26 -0400
It may be that the coda kernel code is not 64-bit clean.  You might go
through it and see if there any uses of types like int/short/long in
interfaces; really there should be none and they all should be
u_int32_t etc.  I'd argue that the user/kernel interfaces should be
defined in terms of fixed-width types rather than floating; this seems
the only sane path since most of them are quantities passed over the
wire as well (fid, etc.).  Since a 32-bit venus will expect int and
long to be 32 bits, it will be out of sync with a 64-bit kernel.

BTW, is linux on sparc64 ILP64, or just LP64?  NetBSD/sparc64 is LP64:

#include <stdio.h>
#include <sys/types.h>

  printf("char %d, short %d int %d long %d long long %d void* %d\n",
         sizeof(long long),
         sizeof(void *));

  printf("int8_t %d, int16_t %d int32_t %d int_64t %d\n",

char 1, short 2 int 4 long 8 long long 8 void* 8
int8_t 1, int16_t 2 int32_t 4 int_64t 8

Jan: is there a specification for the user/kernel interface, beyond
reading the code?  Would you be comfortable making a pronouncement
that the spec is fixed-width types, and that the widths are what the
current code compiles to on i386?

The netbsd code has lots of ifdefs for types, and could be simplified
considerably since u_int32_t etc. are always defined.  I suspect this
is the case on all modern systems - some standard defines these types.
I believe that u_int32_t is a BSDism, and uint32_t is what POSIX/C99
specifies (wtih int32_t being common to both BSD historical practice
and the standards).

        Greg Troxel <>
Received on 2004-07-30 10:38:46