Re: rlimit changes

Re: rlimit changes

[Ulrich Drepper]

[linux only]

I had to modify the changes Andreas made for the rlimit stuff.  They
have to be in 32-bit platform specific directories.  I know that
currently the kernel has the change of the constants in a shared file
but this will change since rth only yesterday found out that this
change was made and he didn't like it (not copatible with OSF).

Besides this for platforms like m68k and probably also Arm the change
was not useful as well.  There will be no 4GB address spaces.

Therefore I've so far enabled the versioning for the rlimit stuff only
on x86.  If after the kernel change this is necessary for other
platforms as well we still can make appropriate other changes.

(Oh, I'll start testing the changes in a bit, so don't complain if
they don't work).

PS: Now glibc should compile on ALpha again.  This wasn't the case
before which was the initial reason why I looked into this.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> [linux only]
|> 
|> I had to modify the changes Andreas made for the rlimit stuff.  They
|> have to be in 32-bit platform specific directories.  I know that
|> currently the kernel has the change of the constants in a shared file
|> but this will change since rth only yesterday found out that this
|> change was made and he didn't like it (not copatible with OSF).
|> 
|> Besides this for platforms like m68k and probably also Arm the change
|> was not useful as well.  There will be no 4GB address spaces.

Huh? What has this to do with 4GB address spaces?

|> Therefore I've so far enabled the versioning for the rlimit stuff only
|> on x86.  If after the kernel change this is necessary for other
|> platforms as well we still can make appropriate other changes.

*All* platforms have the change in the kernel.  It's platform
*independent*!  You have now broken *all* other platforms!

|> (Oh, I'll start testing the changes in a bit, so don't complain if
|> they don't work).
|> 
|> PS: Now glibc should compile on ALpha again.  This wasn't the case
|> before which was the initial reason why I looked into this.

So why don't you just fix Alpha *without* breaking all others???

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Ulrich Drepper]

Andreas Schwab <schwab@suse.de> writes:

> *All* platforms have the change in the kernel.  It's platform
> *independent*!  You have now broken *all* other platforms!

You haven't read the mail.  This will change because it's completely
unnecessary for platforms like Alpha.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> Andreas Schwab <schwab@suse.de> writes:
|> 
|> > *All* platforms have the change in the kernel.  It's platform
|> > *independent*!  You have now broken *all* other platforms!
|> 
|> You haven't read the mail.  This will change because it's completely
|> unnecessary for platforms like Alpha.

Huh?  rlim_t and RLIM_INFINITY has changed on Alpha too.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Thorsten Kukuk]

On Fri, Dec 10, Ulrich Drepper wrote:

> Andreas Schwab <schwab@suse.de> writes:
> 
> > *All* platforms have the change in the kernel.  It's platform
> > *independent*!  You have now broken *all* other platforms!
> 
> 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.

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

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

Re: rlimit changes

[Ulrich Drepper]

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.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> 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.

SUS2 says that rlim_t is unsigned.  Will you ignore that?  This has
nothing to do with the kernel.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Ulrich Drepper]

Andreas Schwab <schwab@suse.de> writes:

> SUS2 says that rlim_t is unsigned.  Will you ignore that?  This has
> nothing to do with the kernel.

It's not my call.  The kernel people will decide and I now that the
guy who's responsible for ALpha (incidently in the office next to
mine) does not want this change.  The type can be unsigned but the
actual limit values nevertheless can remain the same for the platforms
where it makes no sense to have larger values.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> Andreas Schwab <schwab@suse.de> writes:
|> 
|> > SUS2 says that rlim_t is unsigned.  Will you ignore that?  This has
|> > nothing to do with the kernel.
|> 
|> It's not my call.  The kernel people will decide and I now that the
|> guy who's responsible for ALpha (incidently in the office next to
|> mine) does not want this change.  The type can be unsigned but the
|> actual limit values nevertheless can remain the same for the platforms
|> where it makes no sense to have larger values.

So why don't you just wait until the kernel issue settles down instead of
breaking all but the ix86 platform?  Fact is that the libc ABI has
changed, and my changes have restored binary compatibity, but your changes
have remove it without any need.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Ulrich Drepper]

Andreas Schwab <schwab@suse.de> writes:

> So why don't you just wait until the kernel issue settles down instead of
> breaking all but the ix86 platform?  Fact is that the libc ABI has
> changed, and my changes have restored binary compatibity, but your changes
> have remove it without any need.

Because it didn't even compile on Alpha.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> Andreas Schwab <schwab@suse.de> writes:
|> 
|> > So why don't you just wait until the kernel issue settles down instead of
|> > breaking all but the ix86 platform?  Fact is that the libc ABI has
|> > changed, and my changes have restored binary compatibity, but your changes
|> > have remove it without any need.
|> 
|> Because it didn't even compile on Alpha.

What now?  Just because there is a bug on alpha you break sparc, arm,
m68k, powerpc, ...???  Please explain.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Ulrich Drepper]

Andreas Schwab <schwab@suse.de> writes:

> What now?  Just because there is a bug on alpha you break sparc, arm,
> m68k, powerpc, ...???  Please explain.

What is really broken?  The constants for the 32-bit platforms which
are not using the 4GB limit should remain at 2GB and this is infinity.
Even in the kernel.  For 64-bit platforms this is the same.

Only x86 had problems in the first place since now in the kernel 2GB
does not anymore mean unlimited.  This is what your patches fixed.

So, to proceed the current

	sysdeps/unix/sysv/linux/bits/resource.h

file should be copied in an x86 specific dir and the original file
should be changed back to use the old value.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> Only x86 had problems in the first place since now in the kernel 2GB
|> does not anymore mean unlimited.  This is what your patches fixed.

No.  My patches fix the binary incompatibility in the libc ABI.  Nothing
more, nothing less.  This is completely platform independent.

|> So, to proceed the current
|> 
|> 	sysdeps/unix/sysv/linux/bits/resource.h
|> 
|> file should be copied in an x86 specific dir and the original file
|> should be changed back to use the old value.

So why didn't you do that in the first place, instead of breaking all
platforms??

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Ulrich Drepper]

Andreas Schwab <schwab@suse.de> writes:

> So why didn't you do that in the first place, instead of breaking all
> platforms??

Because I really don't care whether it's broken for a day or two until
the kernel issue settled.  And I've left to every port maintainer to
make appropriate changes.  It's just that handling this issue platform
independent was wrong and this is what I corrected.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Thorsten Kukuk]

On Fri, Dec 10, Ulrich Drepper wrote:

> Andreas Schwab <schwab@suse.de> writes:
> 
> > So why didn't you do that in the first place, instead of breaking all
> > platforms??
> 
> Because I really don't care whether it's broken for a day or two until
> the kernel issue settled.  And I've left to every port maintainer to
> make appropriate changes.  It's just that handling this issue platform
> independent was wrong and this is what I corrected.

Short history:

You make a change which breaks the ABI for all platforms for over 
2 weeks. We fixed it for all platforms.
Now you remove the fix for all platfroms and makes a ix86 specific
solution, the ABI for all other platfroms are broken again.
Then you say, the port maintainer should fix it again.

Could you please explain me, why you break it for other platforms,
if the port maintainer should make the changes ? Then make it correct 
and make the changes only for the ix86 platform and wait until the
port maintainer makes the necessary changes. The current solution
is not Ok.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

Re: rlimit changes

[Ulrich Drepper]

Thorsten Kukuk <kukuk@suse.de> writes:

> You make a change which breaks the ABI for all platforms for over 
> 2 weeks. We fixed it for all platforms.

Wrong.  I told you three times already: it didn't even compile on
Alpha.

> Could you please explain me, why you break it for other platforms,
> if the port maintainer should make the changes ? Then make it correct 
> and make the changes only for the ix86 platform and wait until the
> port maintainer makes the necessary changes. The current solution
> is not Ok.

It is not possible to fix the Alpha problems without removing the
generic stuff.  Try it out before complaining.  On Alpha you get
double definitions of the functions because they are picked up in misc
and in resource.

If SuSE wants to make a release, go on, use the old code.  It's simply
not correct on all platforms.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: rlimit changes

[Thorsten Kukuk]

On Fri, Dec 10, Ulrich Drepper wrote:

> Thorsten Kukuk <kukuk@suse.de> writes:
> 
> > You make a change which breaks the ABI for all platforms for over 
> > 2 weeks. We fixed it for all platforms.
> 
> Wrong.  I told you three times already: it didn't even compile on
> Alpha.

Yes, and I told you that I have no problems. I have compiled yet
the glibc 2.1.3 CVS snapshot from yesterday with the missing patches
from Andreas Schwab (which are only in 2.2) on a SuSE Linux 6.3/Alpha.

It compiles, it works. So we should try to find out what exactly
the problem is and what the reason it that it fails for you.

> It is not possible to fix the Alpha problems without removing the
> generic stuff.  Try it out before complaining.  On Alpha you get
> double definitions of the functions because they are picked up in misc
> and in resource.

As I told you already, I have tried it out before complaining. 
The resulting version works, and I get no warnings or errors.
Where you write your problem now, I have looked at the log file.
You are right, oldgetrlimit64.os and oldsetrlimit64.os are included
twice, from misc and from resource. But the linker is not complaining
that he has 2 identical object files, he only use it once. So it
works for me and I had no chance to see it until yet.
 
I think this really shouldn't be so hard to fix, but I'm not a
Makefile expert. And I think there is something other wrong if
rlimit functions are included in misc and in resource.

> If SuSE wants to make a release, go on, use the old code.  It's simply
> not correct on all platforms.

SuSE will never use CVS snapshots for the release, we only adds important
bug fixes to a public relase, where we are sure that this patches will
not break anything else. Snapshots makes to much trouble, as you never
know if they will not break the ABI or something else. And as you could 
read everywhere, we released our new version already. This is the reason 
why Andreas S. and I have now the time to get the current CVS version
working before glibc 2.1.3 will be released public.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Ulrich Drepper <drepper@cygnus.com> writes:

|> It is not possible to fix the Alpha problems without removing the
|> generic stuff.

This is wrong.  Only the lines

ifeq ($(subdir),resource)
sysdep_routines += oldgetrlimit64 oldsetrlimit64
endif

should be moved to the 32 bit arch subdirs.  Everything else is ok.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Jakub Jelinek]

On Mon, Dec 13, 1999 at 10:25:09AM +0100, Andreas Schwab wrote:
> Ulrich Drepper <drepper@cygnus.com> writes:
> 
> |> It is not possible to fix the Alpha problems without removing the
> |> generic stuff.
> 
> This is wrong.  Only the lines
> 
> ifeq ($(subdir),resource)
> sysdep_routines += oldgetrlimit64 oldsetrlimit64
> endif
> 
> should be moved to the 32 bit arch subdirs.  Everything else is ok.

What's so generic about getrlimit.c? It will work on i386, ppc, won't work on alpha,
sparc, sparc64. For other architectures it depends what will be written.
sparc32 at the moment does not define any ugetrlimit syscall, but defines
getrlimit and old_getrlimit.

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

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Jakub Jelinek <jakub@redhat.com> writes:

|> On Mon, Dec 13, 1999 at 10:25:09AM +0100, Andreas Schwab wrote:
|> > Ulrich Drepper <drepper@cygnus.com> writes:
|> > 
|> > |> It is not possible to fix the Alpha problems without removing the
|> > |> generic stuff.
|> > 
|> > This is wrong.  Only the lines
|> > 
|> > ifeq ($(subdir),resource)
|> > sysdep_routines += oldgetrlimit64 oldsetrlimit64
|> > endif
|> > 
|> > should be moved to the 32 bit arch subdirs.  Everything else is ok.
|> 
|> What's so generic about getrlimit.c? It will work on i386, ppc, won't work on alpha,
|> sparc, sparc64. For other architectures it depends what will be written.

It should work on all platforms that still use the old RLIM_INFINITY, and
those that define ugetrlimit.  That should currently be all 2.2 kernels.

|> sparc32 at the moment does not define any ugetrlimit syscall, but defines
|> getrlimit and old_getrlimit.

So sparc32 probably needs it's own getrlimit.  That does not require
removing the generic getrlimit.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: rlimit changes

[Thorsten Kukuk]

On Fri, Dec 10, Ulrich Drepper wrote:

> Andreas Schwab <schwab@suse.de> writes:
> 
> > What now?  Just because there is a bug on alpha you break sparc, arm,
> > m68k, powerpc, ...???  Please explain.
> 
> What is really broken?  The constants for the 32-bit platforms which
> are not using the 4GB limit should remain at 2GB and this is infinity.
> Even in the kernel.  For 64-bit platforms this is the same.

You always speak about 4GB limit. What does the cpu time, open files
or number of processes have to do with the 4GB limit ?

And don't tell me the current limit is enough forever. We had this
very often and it was always wrong.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

Re: 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)
___________________________________________________________________

Re: rlimit changes

[Ralf Baechle]

On Fri, Dec 10, 1999 at 10:01:31AM +0100, Andreas Schwab wrote:

> |> Therefore I've so far enabled the versioning for the rlimit stuff only
> |> on x86.  If after the kernel change this is necessary for other
> |> platforms as well we still can make appropriate other changes.
> 
> *All* platforms have the change in the kernel.  It's platform
> *independent*!  You have now broken *all* other platforms!

As for MIPS, I don't care as the address space is limited to 2gb, therefore
we won't ever use the critical values.

  Ralf

Re: rlimit changes

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

Ralf Baechle <ralf@uni-koblenz.de> writes:

|> On Fri, Dec 10, 1999 at 10:01:31AM +0100, Andreas Schwab wrote:
|> 
|> > |> Therefore I've so far enabled the versioning for the rlimit stuff only
|> > |> on x86.  If after the kernel change this is necessary for other
|> > |> platforms as well we still can make appropriate other changes.
|> > 
|> > *All* platforms have the change in the kernel.  It's platform
|> > *independent*!  You have now broken *all* other platforms!
|> 
|> As for MIPS, I don't care as the address space is limited to 2gb, therefore
|> we won't ever use the critical values.

If the RLIM_INFINITY gets arch dependent in the kernel then there won't be
any reason to use a different value in libc, but I didn't know that this
will happen when I wrote the lines above.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg