[OpenAFS-devel] Re: AFS & IA-64?

[Harald Barth]

> Sorry that I wasn't more explicit in my earlier post. Our workaround has 
> been to use an afs translator system serving us the afs fs as an nfs 
> mount. Not the best answer, but it works somewhat.

NFS, yikes!

If you want to test Arla, here are some hints:

Start with the lastest version in the stable branch (today
arla-0.35.7.tar.gz)

As this is Linux, the configure ; make should just work (ok, I know,
famous last words) for all userland, including arlad. Then you can
test a bit with arla-cli.

The kernel module can be a bit trickier because there is no way to
probe a Linux system for the size of the pointers in the syscall
table. Either it just happens to work because the sizes are right or
it crashes all processes on your box when the kernel module is loades
and modifies the syscall table at the wrong place. When I was porting
Arla to Linux on sparc64, this happened to me as the syscall pointers
are still 32-bit pointers on that architecture, even when all other
pointers are 64-bit. The syscall trap stuff is of course (can you
sense some irritation about the Linux source code here?) written in
assembler without much protoytyping. I pointed that out for the Linux
kernel folks but got only comments back that did not show a greater
understanding of the problem ("a prototype is not necessary", "your
kernel module should not change the syscall table"). There are other
kernel modules that change the syscall table, but these are all
written for a specific architecture. If you need some hints, you can
have a look at
/afs/stacken.kth.se/ftp/pub/arla/random-patches/suse-sparc64-0.35.patch
Please do not apply the whole patch without choosing the right bits
(#ifdef SUSESPECIAL) as that won't work.

Unfortunate for you, noone near the Arla people has seen any value in
buying an ia64 box, and I understand that. Otherwise probably someone
would have done the port allready.

Harald.