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

[Moritz Kiese]

On Mon, 26 Jun 2006, Marco Hoehle wrote:

> Hi Christian,
>
> thanks a lot - it seems to be really dirty -> but working !
>
> Regards
> marco
>
>
> On Fri, Jun 23, 2006 at 02:33:33PM +0200, Marco Hoehle wrote:
>> Hi,
>>
>> after upgrading my ppc64 (IBM OpenPower P720) hosts to a newer kernel
>> release ( von 2.6.7 to 2.6.16) I am unable to build any libafs module on
>> these machines.
>> On the x86 based hosts this is no problem.  OpenAFS release is 1.4.1 - i
>> tried it with 1.4.0 / 1.4.1 / 1.5.0 and 1.5.2.
>>
>> Here is where it breaks . What does this RLIM mean and what can I do to
>> make the module build ?
>>
> please see
> https://lists.openafs.org/pipermail/openafs-devel/2006-April/013770.html
>
> to workaround the problem. Please keep in mind to use 1.4.1-rc10
> (as 1.4.1-final and 1.4.2-beta will oops while searching for the syscall
> tables). Also, don't forget to exec ./regen.sh in the toplevel source
> after changing the *.m4 files.

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 ;)

Best regards,
 	Moritz.