> not that I know of, getting coda running on amd64 is on my (every
> growing) "to do" list.

That's what I thought, but I had to ask.

> > 64k/64u
>
> Ultimately, in my opinion, this is where coda/venus should be - be
> LP64 clean but this will mean some underlying infrastructure changes
> that will mean that old clients & servers will break when combined
> with new clients/servers.  Which may require a "flag day" at a site to
> change everyone over to the new code.  The only out would be if the
> rpc2 interface is versioned or not - I have not checked - if it was
> versioned then some clevers may be pulled in the server code to
> provide some backward compatiability which would obviate the need for
> a flag day.

Agreed.  But I'm not sure we need a wire change, just redefining long
to be int32_t, in effect standardizing on the i386 sizes.  I did this
with amanda/kerberos and it worked.

> > 64k/32u:
>
> [-current and cross tools]

I'm avoiding -current today, but may take the plunge.  I can build
cross tools on 1.6, too.  I suspect the coda source is cross-buildable
- sometimes there is autoconf stuff that builds programs and runs them
to make decisions.

> > 32k/32u:
> 
> Hardly any point in having 64bit capable hardware then, is there? ;)

My thoughts exactly!