On Sat, Jul 31, 2004 at 01:42:47AM +0200, Michael Tautschnig wrote:
> > 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.
>
> Well, I might be completely wrong, but this little bit from
> $KERNEL_SRC/include/linux/coda.h has a "int" in it:

That isn't a problem (on current systems), only the 'long' datatype is
difficult because (afaik) it is defined as the size required to store a
pointer. So it will be a different size on 32- vs. 64-bit CPUs. The
'int' is pretty much a 32-bit value everywhere. The intN_t macros are
there to avoid any possible confusion. f.i. int8_t will always be 8
bits, a char could at some point get changed into something larger
although it looks like there is already a wchar datatype to take care of
that.

>  409 /* coda_ioctl: */
>  410 struct coda_ioctl_in {
>  411     struct coda_in_hdr ih;
>  412     struct CodaFid VFid;

One problem could be in the coda_in_hdr, I see that I've used pid_t,
for which libc might be providing a different size. i.e. 16-bit in the
kernel, 32-bit in userspace, which I believe is the case on cygwin. But
I didn't think this was the case for current Linux kernels and glibc.

However,

    struct coda_vattr
	long va_type
	long va_fileid
	long va_blocksize
	unsigned long va_gen
	unsigned long va_flags

All of those will end up with a different size between a 64-bit compiled
kernel module and a 32-bit userspace. So the whole structure will be out
of sync. This structure is used by getattr (stat), setattr
(chmod/chown/truncate/utimes), create, mkdir, and symlink. Now I don't
really know whether a 64-bit kernel also has 64-bit inode numbers and
such. If that is the case then userspace will have to use int64_t (long
long), otherwise the kernel header should be switched to int32_t (long).

It looks like ino_t (va_fileid) is in fact an int64_t, while va_type
will probably do fine with an int32_t (maybe even int8_t). Interestingly
time_t values are defined as long, while our structure uses an int.

How does the 32-bit 'emulation' on these systems work anyways? How can
they squash down something like a 64-bit inode number or time_t value into
the 32-bit userspace equivalent while maintaining correctness?

Jan