On Sat, Jul 31, 2004 at 02:51:24AM +0200, Michael Tautschnig wrote:
> Ok, I'll try - I already did some more debugging: Actually
> 
>     372         error = mount("coda", venusRoot, "coda",  MS_MGC_VAL,
>     373                       islinux20 ? (void *)&kernDevice : (void
> *)&mountdata);
> 
> in worker.cc fails - could someone quickly direct me to the actual
> definition of "mount"? It isn't the actual system-call, isn't it!?

That is the normal mount(2) syscall, and it is not really the mount
syscall that is failing, although it does return an error to venus..

What happens is that to complete the mount, the kernel needs to return
an initialized inode of the top-level directory (the object we are
mounting on top of /coda). To get the information to initialize this
object, the kernel sends a couple of upcalls. The first one obtains the
Coda file identified (CodaFid) of the object, and then it gets the
attributes (size/owner/modebits).

On Fri, Jul 30, 2004 at 02:21:05AM +0200, Michael Tautschnig wrote:
> coda_read_super: rootfid is (5659bf88.ff000001.00000001.00000001)

Clearly the 'getrootfid' upcall succeeded.

> init_special_inode: bogus i_mode (0)

But the 'getattr' failed. Which is probably because of the alignment
issues in struct coda_vattr.

I've been thinking a bit about the 32 vs. 64-bit issues and why a 32-bit
binary would work. Technically we lose information when squashing a
64-bit value in the 32-bit space, but practically time_t won't wrap
until the year 2038 or something and most on-disk filesystem formats
probably are limited to 32-bit values anyways.

So simply replace the long and u_long values in coda_vattr in the
kernel's coda.h with int32_t and u_int32_t and rebuild the kernel
module.

Jan