From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35953 invoked by alias); 18 Jun 2018 20:18:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 31198 invoked by uid 89); 18 Jun 2018 20:18:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*r:4.89, session, biased, streams X-HELO: albireo.enyo.de From: Florian Weimer To: Carlos O'Donell Cc: libc-alpha@sourceware.org Subject: Re: Future of libio vtable compatibility References: <87h8m41oa0.fsf@mid.deneb.enyo.de> <3a215566-1748-a095-8bfa-c5c1d5017156@redhat.com> <874li0uig3.fsf@mid.deneb.enyo.de> Date: Mon, 18 Jun 2018 20:18:00 -0000 In-Reply-To: (Carlos O'Donell's message of "Mon, 18 Jun 2018 15:22:15 -0400") Message-ID: <87efh3u9vo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-06/txt/msg00522.txt.bz2 * Carlos O'Donell: > Let me pose another question... >=20=20 >> 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 =E2=80=9Cdo not flush on abort or assertion failure=E2=80= =9D 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.