From owner-cvs-all@FreeBSD.ORG Mon Aug 27 22:10:23 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 193B916A418; Mon, 27 Aug 2007 22:10:23 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2870A13C46C; Mon, 27 Aug 2007 22:10:21 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7RMA3QB079129; Tue, 28 Aug 2007 02:10:03 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7RMA27L079128; Tue, 28 Aug 2007 02:10:02 +0400 (MSD) (envelope-from yar) Date: Tue, 28 Aug 2007 02:10:02 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070827221002.GS21352@comp.chem.msu.su> References: <200708270850.20904.jhb@freebsd.org> <20070827.141125.-1573947069.imp@bsdimp.com> <200708271715.21462.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, John Baldwin , 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-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 22:10:23 -0000 On Mon, Aug 27, 2007 at 05:38:08PM -0400, Daniel Eischen wrote: > On Mon, 27 Aug 2007, John Baldwin wrote: > >That > >seems to contradict your earlier changes as you are now saying use 1.1 for > >fts(3), etc. Also since you mentioned MFC'ing one ABI (say 1.5) but not > >others (1.2-1.4), that implies each change in HEAD has its own first-level > >version? > > FBSD_1.1 should get us out a few years. Unless you have an ABI change > that is _already_ in FBSD_1.1, you don't have to create a new version. > > 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? > 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. -- Yar