From owner-cvs-all@FreeBSD.ORG Wed May 28 20:04:43 2008 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 3659A106567F; Wed, 28 May 2008 20:04:43 +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 BCB458FC17; Wed, 28 May 2008 20:04:36 +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.3/8.14.3/NETPLEX) with ESMTP id m4SK4SEv020729; Wed, 28 May 2008 16:04:28 -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-4.0 (mail.netplex.net [204.213.176.10]); Wed, 28 May 2008 16:04:28 -0400 (EDT) Date: Wed, 28 May 2008 16:04:28 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20080528191807.GA8156@zim.MIT.EDU> Message-ID: References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> <20080528060333.GA4699@zim.MIT.EDU> <20080528184143.GA7624@zim.MIT.EDU> <20080528191807.GA8156@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Maxim Sobolev , src-committers@freebsd.org, d@delphij.net, cvs-src@freebsd.org, cvs-all@freebsd.org, Xin LI , re@freebsd.org Subject: Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 20:04:43 -0000 On Wed, 28 May 2008, David Schultz wrote: > On Wed, May 28, 2008, Daniel Eischen wrote: >> On Wed, 28 May 2008, David Schultz wrote: >> >>> On Wed, May 28, 2008, Daniel Eischen wrote: >>>> No, all new symbols in 8-current go into FBSD_1.1, not 1.2. The >>>> only time we go to 1.2 is when 8.x branches to 9.0. If for some >>>> reason memrchr() were to change its ABI, then we would go to 1.1.1 >>>> in -current for the ABI change and any subsequent new symbols, and >>>> the MFC to 7.x would also be 1.1.1. >>>> >>>> It is ok for a FBSD_1.1 in -current to be a superset of FBSD_1.1 >>>> in a previous branch. In fact you can't prevent them from being >>>> different unless you mandate that all new symbols get MFC'd to >>>> their respective namespaces in previous branches. >>> >>> Perhaps I misinterpreted what you said about this last year, but I >>> thought you said you didn't want symbols added to existing >>> namespaces in -STABLE. In 7.X, why would it be okay to add new >>> symbols to FBSD_1.1 between releases but not to FBSD_1.0? >> >> I think you're just off by a version. -stable didn't have >> FBSD_1.1, so we just _did_ add memrchr() to a _new_ namespace >> in -stable. > > Yes, yes, that's fine, that's what I said. But you also said it's > fine to add things to FBSD_1.1 in 7.X, which I think is different > from what you told me last year... > > In practice, this means that if a binary uses FBSD_1.0 and > FBSD_1.1 symbols, the only thing you can say with confidence is > that it will run in 8.0-RELEASE. That's fine with me; I'd just > like to make sure I understand what you do and don't intend to > guarantee. Yes, we decided not to bump versions every time we add a new symbol or ABI change. But we can also record a set of symbols (in a file) for each release, and make some sort of ABI checker that can tell under what releases an application will run. -- DE