Undo setrlimit patch for 2.1.3

Undo setrlimit patch for 2.1.3

[Thorsten Kukuk]

Hi,

Cristian Gafton, Andreas Schwab, Andreas Jaeger and me have the opinium,
that we should revert the setrlimit changes for glibc 2.1.3. Which means,
RedHat and SuSE will ship the next glibc 2.1.3 without the setrlimit
changes.

The reason is simple: We have a binary incompatiblity between glibc 2.1.3
and glibc 2.1.2, but no new functionality or bug fixes.
All Distributors uses the stable 2.2.x kernel, and nobody knows when
2.4 is ready. So it doesn't make sense to have unused support for one
new feature.

Instead, we should try to release glibc 2.1.3 asap. In the moment we
have enuogh bug fixes. Then we should try to make glibc 2.2 stable
and release it with kenrel 2.4. In glibc 2.2 we have a lot of new
features for the new kernel, so we should try to release it at the
same time, and not months later.

Cristian, I hope the patch is ok for you ?

  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: Undo setrlimit patch for 2.1.3

[Philip Blundell]

>2000-01-23  Thorsten Kukuk  <kukuk@suse.de>
>
>	* sysdeps/unix/sysv/linux/i386/getrlimit.c: Move from here ...
>	* sysdeps/unix/sysv/linux/arm/getrlimit.c: ... to here.
>	* sysdeps/unix/sysv/linux/i386/setrlimit.c: Move from here ...
>	* sysdeps/unix/sysv/linux/arm/setrlimit.c: ... to here.

If the consensus is that the rlimit changes should be reverted for i386, we 
may as well back them out for ARM also.

p.

Re: Undo setrlimit patch for 2.1.3

[H . J . Lu]

On Sun, Jan 23, 2000 at 05:49:25PM +0100, Thorsten Kukuk wrote:
> 
> Hi,
> 
> Cristian Gafton, Andreas Schwab, Andreas Jaeger and me have the opinium,
> that we should revert the setrlimit changes for glibc 2.1.3. Which means,
> RedHat and SuSE will ship the next glibc 2.1.3 without the setrlimit
> changes.
> 
> The reason is simple: We have a binary incompatiblity between glibc 2.1.3
> and glibc 2.1.2, but no new functionality or bug fixes.
> All Distributors uses the stable 2.2.x kernel, and nobody knows when
> 2.4 is ready. So it doesn't make sense to have unused support for one
> new feature.
> 

I thought it was handled by the symbol versioning and I had fixed the
linker to do the right thing. Do you have a testcase to show that
glibc 2.1.3 is binary incompatible with glibc 2.1.2? Are you talking
about binaries compiled against glibc 2.1.3 won't run with glibc 2.1.2?
As you may know, it is true even if the setrlimit changes are backed
out, due to those new symbols with version GLIBC_2.1.3.


H.J.

Re: Undo setrlimit patch for 2.1.3

[Thorsten Kukuk]

Hi,

On Sun, Jan 23, H . J . Lu wrote:

> On Sun, Jan 23, 2000 at 05:49:25PM +0100, Thorsten Kukuk wrote:
> > 
> > Hi,
> > 
> > Cristian Gafton, Andreas Schwab, Andreas Jaeger and me have the opinium,
> > that we should revert the setrlimit changes for glibc 2.1.3. Which means,
> > RedHat and SuSE will ship the next glibc 2.1.3 without the setrlimit
> > changes.
> > 
> > The reason is simple: We have a binary incompatiblity between glibc 2.1.3
> > and glibc 2.1.2, but no new functionality or bug fixes.
> > All Distributors uses the stable 2.2.x kernel, and nobody knows when
> > 2.4 is ready. So it doesn't make sense to have unused support for one
> > new feature.
> > 
> 
> I thought it was handled by the symbol versioning and I had fixed the
> linker to do the right thing. Do you have a testcase to show that
> glibc 2.1.3 is binary incompatible with glibc 2.1.2? Are you talking
> about binaries compiled against glibc 2.1.3 won't run with glibc 2.1.2?
> As you may know, it is true even if the setrlimit changes are backed
> out, due to those new symbols with version GLIBC_2.1.3.

Try the following: Compile bash with glibc 2.1.3 and let them run on
a glibc 2.1.2 system. It complains about setrlimit 2.1.3.
But there is no difference between this setrlimit versions, since 
distributors uses linux kernel 2.2.x, not unstable 2.3.x.
The other problem is, that a software vendor, if he uses glibc 2.1.3,
cannot sell his software for 2.1.2 or 2.1.1. He needs an old system
with glibc 2.1 for compiling.

  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: Undo setrlimit patch for 2.1.3

[Thorsten Kukuk]

On Sun, Jan 23, Philip Blundell wrote:

> >2000-01-23  Thorsten Kukuk  <kukuk@suse.de>
> >
> >	* sysdeps/unix/sysv/linux/i386/getrlimit.c: Move from here ...
> >	* sysdeps/unix/sysv/linux/arm/getrlimit.c: ... to here.
> >	* sysdeps/unix/sysv/linux/i386/setrlimit.c: Move from here ...
> >	* sysdeps/unix/sysv/linux/arm/setrlimit.c: ... to here.
> 
> If the consensus is that the rlimit changes should be reverted for i386, we 
> may as well back them out for ARM also.

The ARM developer have to make this decission. Since SuSE doesn't
distribute an ARM version in the moment, we don't have problems if
there is a new ARM setrlimit version or not.

  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: Undo setrlimit patch for 2.1.3

[H . J . Lu]

On Sun, Jan 23, 2000 at 06:21:06PM +0100, Thorsten Kukuk wrote:
> > 
> > I thought it was handled by the symbol versioning and I had fixed the
> > linker to do the right thing. Do you have a testcase to show that
> > glibc 2.1.3 is binary incompatible with glibc 2.1.2? Are you talking
						         ^^^^^^^^^^^^^^
> > about binaries compiled against glibc 2.1.3 won't run with glibc 2.1.2?
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > As you may know, it is true even if the setrlimit changes are backed
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > out, due to those new symbols with version GLIBC_2.1.3.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Try the following: Compile bash with glibc 2.1.3 and let them run on
> a glibc 2.1.2 system. It complains about setrlimit 2.1.3.
> But there is no difference between this setrlimit versions, since 
> distributors uses linux kernel 2.2.x, not unstable 2.3.x.
> The other problem is, that a software vendor, if he uses glibc 2.1.3,

I know. That has been true for glibc 2.0, 2.1, 2.1.1, and 2.1.2. It
will be true for 2.1.3 and 2.2. Everytime when we introduce a new
symbol version, it will happen. Removing the setrlimit change won't
help you on that since there are many other symbols using GLIBC_2.1.3.

> cannot sell his software for 2.1.2 or 2.1.1. He needs an old system
> with glibc 2.1 for compiling.
> 

You didn't answer my question. Please read my email again. I
have highlighted it for you.


H.J.

Re: Undo setrlimit patch for 2.1.3

[Thorsten Kukuk]

On Sun, Jan 23, H . J . Lu wrote:

> On Sun, Jan 23, 2000 at 06:21:06PM +0100, Thorsten Kukuk wrote:
> > > 
> > > I thought it was handled by the symbol versioning and I had fixed the
> > > linker to do the right thing. Do you have a testcase to show that
> > > glibc 2.1.3 is binary incompatible with glibc 2.1.2? Are you talking
> 						         ^^^^^^^^^^^^^^
> > > about binaries compiled against glibc 2.1.3 won't run with glibc 2.1.2?
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > As you may know, it is true even if the setrlimit changes are backed
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > out, due to those new symbols with version GLIBC_2.1.3.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > Try the following: Compile bash with glibc 2.1.3 and let them run on
> > a glibc 2.1.2 system. It complains about setrlimit 2.1.3.
> > But there is no difference between this setrlimit versions, since 
> > distributors uses linux kernel 2.2.x, not unstable 2.3.x.
> > The other problem is, that a software vendor, if he uses glibc 2.1.3,
> 
> I know. That has been true for glibc 2.0, 2.1, 2.1.1, and 2.1.2. It
> will be true for 2.1.3 and 2.2. Everytime when we introduce a new
> symbol version, it will happen. Removing the setrlimit change won't
> help you on that since there are many other symbols using GLIBC_2.1.3.

No. The only external symbol with a new VERSION number is setrlimit,
getrlimit, setrlimit64 and getrlimit64. No others. It works perfect
without this new versions. The other functions are only for internal
use by linuxthreads. So, if you use the same libc/libpthread version,
binaries compiled on glibc 2.1.3 will now run again with glibc 2.1.2,
because the interface is binary compatible between this both versions.
Breaking this for one function without new functionality with current,
stable kernels is something we can avoid here.

The only, good reason for this break is, if you say glibc 2.1.3 will
be the very last version of 2.1.x, and glibc 2.2 will not come this
year. But I hope glibc 2.2 will be ready at the time kernel 2.4 is
released (and we should try this because of 32bit uid_t).

  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: Undo setrlimit patch for 2.1.3

[Jakub Jelinek]

On Sun, Jan 23, 2000 at 05:49:25PM +0100, Thorsten Kukuk wrote:
> 
> Hi,
> 
> Cristian Gafton, Andreas Schwab, Andreas Jaeger and me have the opinium,
> that we should revert the setrlimit changes for glibc 2.1.3. Which means,
> RedHat and SuSE will ship the next glibc 2.1.3 without the setrlimit
> changes.
> 
> The reason is simple: We have a binary incompatiblity between glibc 2.1.3
> and glibc 2.1.2, but no new functionality or bug fixes.
> All Distributors uses the stable 2.2.x kernel, and nobody knows when
> 2.4 is ready. So it doesn't make sense to have unused support for one
> new feature.
> 
> Instead, we should try to release glibc 2.1.3 asap. In the moment we
> have enuogh bug fixes. Then we should try to make glibc 2.2 stable
> and release it with kenrel 2.4. In glibc 2.2 we have a lot of new
> features for the new kernel, so we should try to release it at the
> same time, and not months later.
> 
> Cristian, I hope the patch is ok for you ?

We have this in the tree (sorry for not posting it here but it was a very
last patch I mailed before I went home).
I have reverted even signedness rlim_t changes because it really does not
fix anything, it is just a new feature, but I have kept the @GLIBC_2.1.3
symbols, so that binaries already compiled against it continue to work and
we don't have to change that symbol in 2.1.90 (but symbols @GLIBC_2.0 are
default).
Unless someone is linked against 2.1.3 symbols, the patch should present one
single difference against glibc 2.1.2 - if glibc 2.1.3 with this patch is
compiled with 2.3.3x+ headers and run with such kernel, one can use
getrlimit64/setrlimit64 to query/set resource limits above 2G on i386/arm
(because those functions are using internally __new_[gs]etrlimit even
in @GLIBC_2.0 symbols).
IMHO no matter which patch is applied to 2.1.3, in 2.1.90
oldsetrlimit64/oldgetrlimit64 should call the __new_* non-LFS functions
internally.

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

Re: Undo setrlimit patch for 2.1.3

[Thorsten Kukuk]

Hi,

On Sun, Jan 23, Jakub Jelinek wrote:

> On Sun, Jan 23, 2000 at 05:49:25PM +0100, Thorsten Kukuk wrote:
> > same time, and not months later.
> > 
> > Cristian, I hope the patch is ok for you ?
> 
> We have this in the tree (sorry for not posting it here but it was a very
> last patch I mailed before I went home).
> I have reverted even signedness rlim_t changes because it really does not
> fix anything, it is just a new feature, but I have kept the @GLIBC_2.1.3
> symbols, so that binaries already compiled against it continue to work and
> we don't have to change that symbol in 2.1.90 (but symbols @GLIBC_2.0 are
> default).

No, I think this is the wrong way. We should remove the setrlimit@GLIBC_2.1.3
symbols, too. It is no problem to break binary compatiblity with test
versions. But to let the 2.1.3 version in is ugly and not necessary.

  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: Undo setrlimit patch for 2.1.3

[Scott Bambrough]

Philip Blundell wrote:
> 
> If the consensus is that the rlimit changes should be reverted for i386, we
> may as well back them out for ARM also.
> 

I'm in agreement here.  However I would like to see one more prerelease tarball
set before release.

Scott


-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

Re: Undo setrlimit patch for 2.1.3

[Cristian Gafton]

On Sun, 23 Jan 2000, H . J . Lu wrote:

> I know. That has been true for glibc 2.0, 2.1, 2.1.1, and 2.1.2. It
> will be true for 2.1.3 and 2.2. Everytime when we introduce a new
> symbol version, it will happen. Removing the setrlimit change won't
> help you on that since there are many other symbols using GLIBC_2.1.3.

How about this: I recompiled the whole Red Hat distribution against glibc
2.1.3 with the setrlimit changes. There are dependencies introduced in
some binaries for glibc 2.1.3 now. Of all the dependencies, 100% (like in
*all* of them) are dues to the setrlimit change).

I know there are other changes; I know people using explicitly the new
functions will bite it anyway. I know setrlimit is not that different from
that case. But it has a huge potential to cause more pain than be usefull.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton@redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "How could this be a problem in a country where we have Intel and 
   Microsoft?"  --Al Gore on Y2K