Re: Future of libio vtable compatibility

[Carlos O'Donell <carlos at redhat dot com>]

On 06/18/2018 01:13 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 06/15/2018 03:50 AM, Florian Weimer wrote:
>>> Should we instead remove the compatibility logic altogether?
>>
>> The libio vtable internal ABI compatibility has been a real source 
>> of pain over the years, and it has prevented the general cleanup 
>> of the libio code.
> 
>> I'm inclined to argue that glibc 2.x should remain compatible with
>> the old internal ABI of the vtables, but that perhaps a future glibc
>> with a new major version might drop it entirely.
> 
> But how do we test this?  We learned about the incompatibility only
> because there's an unambiguous error message about it.  Remember that
> none of the affected people tried to report this upstream.  The two
> internal cases we had end up with the users upgrading their obsolete
> binaries anyway (we didn't get the binaries that reproduced the
> issue).

Let me pose another question...
 
> It almost looks to me as if nobody really wants that level of
> backwards compatibility.

Assume you had reliable test system with 100 tests for the backwards
compatibility support.

Given the tests, would you still make the same argument for removal?

Is the argument about poor testing semi-independent of the argument for
removal?

Should we focus our discussion on the core issue?

Is this a part of a broader discussion to rid glibc of external projects
which depend on implementation internals?

Is "libio vtable compat removal" the best value?

As opposed to fixing the Rust dependency on TLS size API.

Or the libasan issues too.

I don't have a good answer to this, but it's the kind of internal
reflection I'm making about the various parts of our APIs that are
being used by other projects.

> We could require that vtable compatibility requires setting an
> environment variable in glibc 2.28.  This might finally allow us to
> gather some data.  Either nobody needs backwards compatibility, or our
> backwards compatibility is just too perfect.  It's difficult to tell
> why we don't see more bug reports in this area.

We all suspect that nobody needs it. That everyone upgraded through
the libstdc++ timeline in which it existed, or doesn't run those
binaries on new systems because of other unrelated dependencies.

The reason behind my suggestion for making this change in glibc 3.0
is completely one of optics. To ensure that our users see us making
big compatibility changes only on major project boundary changes.

To be honest I don't care if we call the *next* release glibc 3.0,
and remove the vtable libio compat code *today* :-)

I also do not think we need to line up dozens of ABI breaking changes
to make glibc 3.0 valuable. For example in glibc 3.0 we can drop all
of the libio vtable compat, and get DJ's patch in to remove the
malloc hooks (which now use a distinct prelodable library). Call it
done. Then in glibc 4.0 we might unify all the libraries into one
if that's what we decide.

Cheers,
Carlos.