Coda File System

Re: 64-bit issues

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 30 Jul 2004 11:32:04 -0400
On Fri, Jul 30, 2004 at 10:35:26AM -0400, Greg Troxel wrote:
> 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?

I thought the interface used fixed types as I remember that some people
successfully ran a 32-bit venus on sparc64/solaris. Peter once wrote up
some documentation when he implemented the first version of the Linux
Coda kernel module.

> 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).

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.

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. 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.

Jan
Received on 2004-07-30 11:34:28