On Sat, 7 Feb 1998, Jim Doyle wrote:

> 
> Tonight, as a respite from my DCE hacking, I decided to give a go at
> porting Coda to Linux/Alpha. I am running Redhat 5.0 (2.0.32 kernel) on
> several fairly beefy Alpha servers.
> 
> There are 64-bit safety hazards throughout Coda. I dont believe any of
> them will be difficult to fix - its just really busy work. For those
> of you that dont understand this:    A virtual memory address (i.e. a 
> void * or an anything *) is a 64 bit integer. This corresponds to
> the "unsigned long int" datatype. On non-AXP machines (Intel, SPARC, PPC),
> a virtual memory address is 32-bits, and can fit into an "int" type.
> 
> Now would be a good time (or, at the next Coda src freeze point) to
> go make Coda 64-bit safe. As I said its just alot of busy work.
> 

I will gladly volunteer as a tester for anything you can come up with.
I'd really like to participate in the coding, but the sheer volume of
source is absolutely overwhelming, and I'm not aware of any "roadmap"
documentation :-(.

Under Intel Linux, I've yet to get through my basic networking test:

- Copy linux source tree to coda volume
- Do 'make mrproper'
- Do 'make xconfig'
(etc.)

Copying the source to the server takes almost an hour (and, yes, I do have
the metadata and log on their own partitions).  This is incredibly slow..

Make mrproper fails on the first pass because it still thinks that
directories it has just cleaned of files are busy.  

If I clean by hand, and attempt xconfig it fails with random corrupted
files.

Smaller applications will build (most of the time), but something's broken
somewhere.  Any ideas where to look?

Steve