From owner-cvs-src@FreeBSD.ORG Mon Aug 27 22:24:29 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEF916A41B; Mon, 27 Aug 2007 22:24:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF1313C45E; Mon, 27 Aug 2007 22:24:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7RMOIon012393; Mon, 27 Aug 2007 18:24:18 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Mon, 27 Aug 2007 18:24:18 -0400 (EDT) Date: Mon, 27 Aug 2007 18:24:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Yar Tikhiy In-Reply-To: <20070827221002.GS21352@comp.chem.msu.su> Message-ID: References: <200708270850.20904.jhb@freebsd.org> <20070827.141125.-1573947069.imp@bsdimp.com> <200708271715.21462.jhb@freebsd.org> <20070827221002.GS21352@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, John Baldwin , peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 22:24:29 -0000 On Tue, 28 Aug 2007, Yar Tikhiy wrote: > On Mon, Aug 27, 2007 at 05:38:08PM -0400, Daniel Eischen wrote: >> >> An example (for the sake of this example, let's assume that all >> non-fts symbols are in FBSD_1.0, and fts_* are in FBSD_1.1): >> >> FILE changes in -current, the new symbol map would add the FILE-related >> APIs. >> >> FBSD_1.1 { >> fts_open; <- existing >> fts_read; <- existing >> ... >> fts_close; <- existing >> fopen; <- new >> fread; <- new >> ... >> fclose; <- new >> } FBSD_1.0; >> >> A week later, pthread_mutex_t changes in -current. You add the >> pthread_mutex_t-related APIs: >> >> FBSD_1.1 { >> fts_open; <- existing >> fts_read; <- existing >> ... >> fts_close; <- existing >> fopen; <- existing >> fread; <- existing >> ... >> fclose; <- existing >> pthread_mutex_init; <- new >> pthread_mutex_lock; <- new >> ... >> pthread_mutex_destroy; <- new >> } FBSD_1.0; >> >> You are not forced to rebuild any ports by adding symbols to FBSD_1.1. >> Everything that was built before the pthread_mutex_t change will work >> after the change. You can keep adding to FBSD_1.1 and only need to >> go to FBSD_1.2 if one of the APIs in FBSD_1.1 undergoes yet another >> ABI change. > > I guess everything will work after changing pthread_mutex_t if either > nothing calls pthread_mutex functions or compatibility shims for them > are provided under FBSD_1.0. Is it correct? Yes, though I was assuming that compat shims are added whenever you change the ABI. For this example, we know that there are a lot of applications that use pthread_mutex-related APIs, so the appropriate compat shims would definitely be needed. >> If the fts_* stuff goes in now as FBSD_1.0, I guess you don't >> need to go to FBSD_1.1. You can stay at FBSD_1.0 until you >> have the next ABI change. If fts_* goes in now as FBSD_1.1 (and >> assuming all the other symbols stay at FBSD_1.0), then you can >> just keep adding to FBSD_1.1 after the branch/release. If all >> the symbols along with fts get pushed to FBSD_1.1, then you >> have to go to FBSD_1.2 at the next ABI change. > > Just to make things clear: if FBSD_1.0, FBSD_1.1, and FBSD_1.2 are > already populated with some symbols and a symbol from FBSD_1.0 > undergoes an incompatible change, which version it should be promoted > to, FBSD_1.1 or FBSD_1.2? AFAIK, technically either is possible. Correct, you can add the new APIs to either FBSD_1.1 or FBSD_1.2, and I do raise this question (as a TBD) in: http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt I would think that we would always use the latest version when adding new ABI changes to -current. In release branches, MFCs have to go the the same version from which they came in -current (to maintain forward compatibility). -- DE