From owner-cvs-src@FreeBSD.ORG Mon Aug 27 21:38:20 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 0E66716A46B; Mon, 27 Aug 2007 21:38:20 +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 CF08313C49D; Mon, 27 Aug 2007 21:38:19 +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 l7RLc8QX014673; Mon, 27 Aug 2007 17:38:08 -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 17:38:08 -0400 (EDT) Date: Mon, 27 Aug 2007 17:38:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200708271715.21462.jhb@freebsd.org> Message-ID: 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; format=flowed Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" , yar@comp.chem.msu.su 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 21:38:20 -0000 On Mon, 27 Aug 2007, John Baldwin wrote: > On Monday 27 August 2007 04:55:31 pm Daniel Eischen wrote: >> On Mon, 27 Aug 2007, M. Warner Losh wrote: >> >>> In message: <200708271529.42264.jhb@freebsd.org> >>> John Baldwin writes: >>> : And yes, I do think it's ok for -current to have rougher edges. After > all, we >>> : aren't really trying to get people running -current on production > systems. >>> >>> I think it is OK for -current to have rougher edges. I don't think it >>> is OK to require -current to have rougher edges. >> >> I think we can agree on that! I also think there is some confusion >> over whether adding ABI changes to an existing symbol version would >> force us to rebuild ports. It doesn't. Once symbol versioning is >> released in 7.0, we can create a new version (FBSD_1.1, or add to >> the existing FBSD_1.1 depending on how the FTS stuff goes) and add >> all the (non-overlapping) ABI changes we want to it _without_ having >> to rebuild ports. This is a tremendous advantage over -current as >> it is today. > > So you want to just bump the version everytime a change happens in HEAD? No, I don't see how you get that from what I said... > 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. 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. -- DE