Re: Future of libio vtable compatibility

[Florian Weimer <fw at deneb dot enyo dot de>]

* Carlos O'Donell:

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

Probably not.  Depends how good the tests are.  If lack of testing of
those internal interfaces does not prevent library cleanups and other
changes (such as the implement of fgetln, biased locking for stdio
streams, or *printf speed-ups),

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

I think the lack of a testsuite is a huge upfront cost if we ever
tackle libio modernization.  And if we treat vtables as an internal
implementation detail, it's significantly easier to achieve some
decent level of coverage.

If give up the notion of vtable compatibility (or internal, data
structure layout compatibility), it will be somewhat easier to
convince that certain fixes are acceptable.

For example, with virtual methods, the call graph between virtual
methods is part of the API, and also the relative order of internal
calls.  Or look at the marker support (see struct _IO_marker).  I'm
not sure which of the streams are compatible with that.

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

I don't think so.  I'm not sure such a project even exists.  The
issues are far too disparate for that.

> Is "libio vtable compat removal" the best value?

I'm not even sure to what extent the vtables constrain us in terms of
the changes we want to make.  Sure, code cleanups are basically
impossible right now, but what are the changes we want to make and
people want to work on, and which are at risk due to the vtable
complexity?

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

There is this one glibc bug I mentioned. 8-)

> 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'm worried that it would lead to the hospitalization of a few people
if we did that *now*. 8-/  The first major version change will
certainly be hardest, based on the Linux experience.

I considered the “do not flush on abort or assertion failure” a glibc
3.0 project too.

Hmm, it looks like never posted the glibc 3.0 notes from last year's
Cauldron session to the wiki.  I should really upload the notes you
sent to me.