rlimit changes

[Jakub Jelinek]

On Fri, Dec 10, 1999 at 07:39:57AM -0800, Ulrich Drepper wrote:
> Thorsten Kukuk <kukuk@suse.de> writes:
> 
> > > You haven't read the mail.  This will change because it's completely
> > > unnecessary for platforms like Alpha.
> > 
> > In your first mail, your wrote that you have problems with Alpha.
> > Now you write it is unnecessary. This is not the same.
> 
> I have problems and because of those I went to see rth who said the
> change is unnecessary and not welcome.  This isn't so hard to
> understand.  You haven't even tried to compile on Alpha to see how
> broken it was so don't complain.
> 
> > What is with SPARC ? Andreas has made the patches because we need
> > them on 32 bit SPARC (I haven't test it on SPARC64 yet).
> 
> Wel, then make the changes to the SPARC tree.  But since there is no
> ugetrlimit syscalls the question is whether it was wanted there at
> all.  The x86 is a special case since it actually allows 4GB memory
> and more.  Is this true for SPARC?  If not the kernel change is not
> necessary at all and *will* (note: future tense!!!) be changed back.
> All it does in this case is adding more core where it never serves any
> purposes.

There are sparc 32bit boxes (SC2000/SS1000) with up to 20GB or so, but
we do not support them (at most 2GB). It should not be hard with the
new kmap infrastructure but
a) I have just .5GB in such a machine
b) it is lame slowish machine so I think I'll better spent my time on
something else

I don't have SuS handy, but does it say anything about the RLIM_INFINITY
value? E.g. on Solaris it is either 0x7FFFFFFF, or (unsigned long)-3,
depending if it is non-LFS or LFS compilation. In 64bit, it is always
(unsigned long)-3.

I strongly vote for RLIM_INFINITY being architectural define, so that
architectures can choose their constants.
We can choose any value on sparc64 in fact, because the userland is not cast
in stone yet (BTW: David, your merge is buggy because sys_sparc32.c
still works with RLIM_INFINITY32 as 0x7FFFFFFF so the syscall change is
completely unnecessary. I think we should go with 32bit RLIM_INFINITY
0x7FFFFFFF and 64bit RLIM_INFINITY can be easily 0xFFFFFFFFFFFFFFFF).
But there should definitely not be two syscalls in sparc 64bit userland,
that's stupid.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.26 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________