(Illustration by Gaich Muramatsu)
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 -Received on 1998-02-08 21:22:26