From mboxrd@z Thu Jan  1 00:00:00 1970
From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme, rio workalike available in plan 9 ports
In-Reply-To: <20040423152948.GA23473@lst.de>
Message-ID: <Pine.LNX.4.44.0404230943460.19442-100000@maxroach.lanl.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Fri, 23 Apr 2004 09:54:48 -0600
Topicbox-Message-UUID: 6b278936-eacd-11e9-9e20-41e7f4b1d025

On Fri, 23 Apr 2004, Christoph Hellwig wrote:

> > Let's take program 'a', which depends on stat. In the new order of gcc,
> > when built, 'a' will depend on stat from glib 2.0. A new stat comes along
> > with fixes. It gets built into glibc 2.1. You install glibc 2.1. Program
> > 'a', unless I rebuild or replace it, will be using the old stat. Of
> > course, I might think that the shared library has fixed all binaries using
> > stat, and I'm wrong -- or am I right? Is the V1 stat just a wrapper? who
> > knows? And do you cover all the cases?
> 
> Stop here.  You don't get a new symbol version just because your new
> version ends up in a new glibc.  so unless your fix changes the
> interface to stat it will retain it's old symbol version.  Bumping the
> symbol version is an explicit action of the program author.  And because
> of the maintaince issue they rewrite the old version as a wrapper around
> the new one in every case I've seen so far.  If this wasn't the case
> _and_ the author wouldn't update the version that would be considered a
> huge bug indeed.   But that's not what happens in real life.
> 
> I've looked for an example that shows this without too much code and
> while we're at it shows some glibc braindamage (messing up kernel
> syscalls when translating them to library calls), and that would be the
> sched_getaffinity call, implemented in
> sysdeps/unix/sysv/linux/sched_getaffinity.c.
> 
> We have a routine called __sched_getaffinity_new implementing a small
> wrapper for the sched_getaffinity syscalls.  With
> 
> versioned_symbol (libc, __sched_getaffinity_new, sched_getaffinity,
>                   GLIBC_2_3_4);
> 
> it's exported as sched_getaffinity for the symbol version GLIBC_2_3_4.
> 
> Then
> 
> int
> attribute_compat_text_section
> __sched_getaffinity_old (pid_t pid, cpu_set_t *cpuset)
> {
>   /* The old interface by default assumed a 1024 processor bitmap.  */
>    return __sched_getaffinity_new (pid, 128, cpuset);
> }
> compat_symbol (libc, __sched_getaffinity_old, sched_getaffinity, GLIBC_2_3_3);
> 
> implements the older version ontop of the new one.
> 

Well, here are details I was reluctant to put into email due to my 
sensitive nature. 

But take this one comment: 

>And because of the maintaince issue they rewrite the old version as a
>wrapper around the new one in every case I've seen so far.

I think you're assuming a lot now and into the future. But I'll take your
word for it.

I think unless I'm wrong that you've actually demonstrated the problem I'm
trying to show -- an old binary, using a broken interface, doesn't get
fixed just because you update the library. What happens is that the old
binary retains the broken interface. This is not what people think of with
shared libraries -- they naively think you upgrade the library and good
things happen, bugs are fixed, angels sing. glibc retains old broken
interfaces as time moves forward -- is this really a good idea?

In other words, shared libraries certainly solve a problem, but I'm not
sure any more which one it is.

ron