From owner-cvs-all@FreeBSD.ORG Mon Aug 27 17:36:28 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F55616A417; Mon, 27 Aug 2007 17:36:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id A702E13C483; Mon, 27 Aug 2007 17:36:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k2) with ESMTP id 205636794-1834499 for multiple; Mon, 27 Aug 2007 13:36:33 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7RHaBsF028954; Mon, 27 Aug 2007 13:36:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Daniel Eischen Date: Mon, 27 Aug 2007 13:21:06 -0400 User-Agent: KMail/1.9.6 References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <200708271041.23205.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708271321.08014.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 27 Aug 2007 13:36:12 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4076/Mon Aug 27 10:15:54 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Warner Losh , yar@comp.chem.msu.su Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 17:36:28 -0000 On Monday 27 August 2007 01:10:14 pm Daniel Eischen wrote: > On Mon, 27 Aug 2007, John Baldwin wrote: > > > > Perhaps a more useful discussion would be how can we use symbol versioning > > sanely to support this in the future? The fbsd.hack idea could work, but > > it doesn't work in this case because the existing binaries are already > > linked. One suggestion that could start with 8.0 could be this: > > > > - when bumping the version for a symbol in HEAD, instead of going from > > fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0. You > > can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent > > changes > > - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0 > > symbol versions for the current versions of all the bumped symbols, and > > remove all the fbsd-current-* versions and compat shims before the > > release (before the RELENG_X+1_0 branch in fact). The rule there being > > that no release should ever ship with visible fbsd-current-* symbol > > versions. > > I don't think you need intermediate symbol versions, one should be > sufficient. The problem would only arise if you make an ABI change > to a function or set of functions that have already had an ABI change > in the current version. For example, if there were a function > ftsfwrite(FTS, FILE *, ...), and you make the version bump from > FBSD_1.0 to FBSD_1.1 when FTS changes, then if FILE changes, you > need to bump FBSD_1.1 to FBSD_1.2. If there are no overlapping > changes in the ABI, you can continue to add newly changed symbols > to the current version (in this case FBSD_1.1). Actually, what we have now with fts(3) is exactly this: two versions of the symbols that wish to be called fbsd_1.0. By using a late binding of the "official" fbsd_X.0 version we can avoid that. It also provides a way to delineate ABI changes that aren't visible to releases and -stable branches. They will exist in HEAD with only having a fbsd-current symbol, so they can be axed from HEAD safely. > How may times have we ever had overlapping ABI changes in the past? > Have we ever? It's not worth fiddling with intermediate symbols, > because with that method you're still forcing -current users to > rebuild everything just before or after RELEASE to get the final > symbols (when the intermediates are removed). If there are no > overlapping ABI changes, then no one has to rebuild any ports. You don't have to remove the compat shims from HEAD right away. Remember, release is on a _branch_: RELENG_X. You remove the compat shims from the branch before the release, but you can use discretion as to when you actually remove them from HEAD. -- John Baldwin