Hello Jim,

I enjoyed talking to you a lot.  It's great you are tinkering with an
AXP port for Coda. 

Regarding a CVS compatible checkout.  Just pick up the 4.3.13 tarball,
this is tagged as 4.3.13 and has CVS subdirectories.  

I hope this message will give you and others on the list a bit more
perspective on what I perceive needs to be done.  I fully agree with your
statement about why it is important and your initial observations. 
However, your message picks up a macro which is wrong, I feel there is
rather more at stake to get a system that works smoothly between 64 and 32
bit clients and servers when mixed. Here are my thoughts. 

Most 64 bit machines now have an LP design. This means that Longs and
Pointers are 64 bit, integers remain 32bit and shorts remain 16. Initially
ILP designs were used too, but these have largely disappeared.  An
_excellent_ paper on porting 32->64 bit issues appeared in ;login:  (sp?) 
a month or two ago and can also be found in Go Solo 2 (from
opengroup..org).  I strongly recommend you read that again so that we are
exactly on the same frequency discussing this. 

Regarding the Coda code the following:

- the key issue is to get the types right so that a 64 bit Venus can
talk to a 32 bit server. This involves many steps, some of which are
quite involved.

a) first you will need to port lwp to use some Alpha assembly for
context switching.  Such code is shown in the RX package available
from Transarc and can be adapted for Coda.  Should not be hard.  There
are a few test programs in the lib-src/mlwp directory which will
confirm basic functionality of the package. It's great that you can do
this so easily. Please fire off. 

b) I would then proceed to rpc2.  This uses many longs, but most are
carefully defined as RPC2_Long.  RPC2 would have used ints if it had
been written in 1998 -- in view of the LP business.  Many of these
longs go over the net so need to be 32 bit to match other platforms. I
would continue to have a layer of indirection between the system and
RPC2, using types like RPC2_Long or better RPC2_Int, but make sure
that it uses 32 bit ints.

There are test programs in the rpc2 package and these should be run
from an Alpha machine to a 32 bit architecture.  This might be a bit
of work but should be straightforward.

c) From here we go to RVM. RVM is our transaction package (Recoverable
virtual memory).  RVM is probably 64 bit clean but there is probably also
a flag which would be desirable to use, to enable the following. Even on
32 bit architectures, RVM supports data segments which are longer than
2^32 bytes.  It does this by managing OFFSET types (or something like it) 
which have a high and a low component for the lower and higher 32 bits.

On AXP of course we should exploit 64 bit alpha arithmetic and rvm is
already prepared to do this.  Why don't you browse that code and see
if you can compile it, and run the rvm_basher.  This basher is a
pretty good test of rvm, but you can only be satisfied that your code
is right when it can run stably for days at a time.


d) The next thing is to modify the rpc2 stub files (extension .rpc2,
mostly in coda-src/vicedep) _AND_ coda.h so that on AXP the types are
correct.  These are the things going over the network so they need to
exactly match the types found on 32 bit architectures.

Again, there are some small test programs which use this stub
generator.  The simples two I can think of are the auth server and au
(a small client) and the update server and client.  These would be
easy to build and test across the 32/64 boundary.

coda.h is contained in kernel-src/vfs/includes.  It is the single file
which is shared by user level code and kernel code and it contains a
typedef for ViceFids (which travel all the way from servers into kernel --
so they need to be 32/6 bit safe).  The longs here should become ints. 

There is a small program called potemkin which would test an awful lot of
this stuff.  Potemkin works with the kernel like Venus, and "serves" a
local directory.  So insmod coda potemkin -rd /home/braam mounts /coda and
all operations on /coda are redirected to operations in /home/braam by
potemkin. 

e) The disastrous part is that fairly often in the code various
programmers have used a "long" here and a VnodeT (Vnode type) there and
freely assign one to the other. 

These are the same on 32 bit, but NOT on AXP.  Finding all these longs and
replacing them with the appropriate type is going to be quite a bit of
work.  It will also require great familiarity with the code since in
effect every long defined in Coda is suspect and will have to be
investigated.  Perhaps I am the right person to help with that, since I
know what most things are used for. 

This happens particularly in the Volume package. This package writes
metadata to the RVM data files and I would want the layout of this data to
be platform independent (as much as possible, read on).  If not, we could
not dump a volume on one host and restore it on another. 

There are however some areas here where it is vital that true 64
quantities are stored.  RVM holds pointers -- it must therefore be mapped
into memory at exactly the same address each time the server starts. 
These pointers are to become 64 bit.  Also most information is not stored
in network order, though things that travel from one host to another (such
as directories) _are_ stored in network order. 

This is a marvellous thing to work on.  I hope you will follow the order
above, so that if you don't have time to complete it, others can take over
easily by picking up where you left off.  When you get close to e) contact
me, since I think I should do e) to make sure we catch all longs! 

- Peter -