Sorry - I've lost the mail that arrived kindly replying about the patch
I sent in.  The ultrasparc mail server was having fits over an external
disk that just decided to lose its ventilators and overheat.  Apologies.
Anyway ...

As I recall:

1) I used gcc 2.8.something (probably 0 as I like 0). and all of the
   changes I made were to avoid compile errors, not compile warnings.

2) In particular, wrongly typed nulls seem to be a no-no under gcc 2.8.*.
   But they were easy to catch. Just tedious.

3) I compiled against linux 2.0.25, which maybe explains why you didn't have
   to do one of the includes that I did have to do. Clearly an autoconf case.
   Testing for time structures is a standard thing in autoconfs. Inclusion
   orders change.

4) I believe const (as in char[]) -> nonconst is an ansi error and gcc hoots
   on it nowadays.

I don't recall if parts of coda needed g++ as opposed to gcc.  If so
that would explain extra pickiness.  Anyway, if you have the patches

And -O2 may be bad for you (debugging) but it's great for me (using).
I can't put it any more strongly than saying you _must_ set up the
distribution for use, not for development.  I doubt if I had 100M
available to do a -O0 -g compilation in! 

uh ..  and the raid5 over nbd is undergoing production tests, as is (in
a mild way) a 1GB coda 4.6 server.

Yes and no - to do a multiway feed via raid5 over the net you have to
do some tricks.  I am just testing a straightforward raid5 mirror to a
device on a co-server from a server that is feeding nfs clients with the
composite device. It's only intended to provide an uptodate backup
image of the state (modulo an e2fsck) in case we lose the main server.
It should be accurate to 30s.  (the arrangement is actually symmetric -
each server backs up the others play area, but never mind). If one
actually goes down we have to e2fsck and ip-alias for the missing one by
hand.


Regards

ptb