[OpenAFS-devel] not sure what to do about rlim --- also on other 64 bit machines?

[Troy Benjegerdes]

> I'm wondering whether this would help also with other 64-Bit machines. 
> Doing some handhacking and selecting the right #defines with 1.5.2, get's 
> me past this rlim error --- due to SMP EXIT_ZOMBIE has to be put in 
> afs_osi.c a couple of times, but then it complains about
> 
> /usr/src/openafs-1.5.2/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_vnop_flock.c:176: 
> error: struct task_struct has no member named p_opptr
> 
> Any ideas on that? This seems to be another macro gone wild, but I can't 
> really tell where and how...
> 
> The machine in question is a x86_64 running 2.6.16.13-4 (seems to be a 
> SuSE 10 default installation --- in case you're more happy w/ another 
> distro I'll talk to the guy who has to work with this thing). I've tried 
> OpenAFS 1.5.1, 1.5.2, 1.4.1. I just need a pointer in the right direction 
> --- haven't looked at Linux kernel for years and it looks quite different 
> to me ;)

I managed to build OpenAFS 1.4.1 on 2.6.17 (kernel.org) on a PPC64
machine, using 
"CFLAGS='-m64' ./configure --with-linux-kernel-headers=/usr/src/linux-2.6.17"

However, I also patched either osi_probe.co or osi_syscall.c to completely
skip the syscall table probeing. The patch is at work, so I can't post it
right now. If you don't do the syscall table patch, you won't have correct
PAG support, but you can at least have a working afs client instead of
one that panics the kernel.

(And while I'm talking about the syscall table patching, does anyone
have time and/or resources to try using the kernel keyring support that
is in the 2.6.16 (and newer) kernels instead of having to use the PAG
and group-based hacks? What code needs to change to make this work?