From owner-cvs-src@FreeBSD.ORG Wed May 28 15:08:07 2008 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 7CC82106564A; Wed, 28 May 2008 15:08:07 +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 2A72E8FC22; Wed, 28 May 2008 15:08:06 +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 m4SF7phW001108; Wed, 28 May 2008 11:07:51 -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 11:07:51 -0400 (EDT) Date: Wed, 28 May 2008 11:07:51 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20080528060333.GA4699@zim.MIT.EDU> Message-ID: References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> <20080528060333.GA4699@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-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: Wed, 28 May 2008 15:08:07 -0000 On Wed, 28 May 2008, David Schultz wrote: > On Tue, May 27, 2008, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Maxim Sobolev wrote: >> | Xin LI wrote: >> |> delphij 2008-05-27 20:04:27 UTC >> |> >> |> FreeBSD src repository >> |> >> |> Modified files: (Branch: RELENG_6) >> |> include string.h lib/libc/string >> |> Makefile.inc memchr.3 sys/sys param.h Added >> |> files: (Branch: RELENG_6) >> |> lib/libc/string memrchr.c Log: >> |> MFC: Add memrchr(3). >> | >> | I think this is not very good idea to MFC that into stable releases 6.x >> | and 7.x. The reason is that configure scripts for some packages might >> | detect up this API and enable it. Which means that some binary-only >> | packages build for say 6.4 won't work on 6.3 and down. AFAIK, both >> | forward and backward compatibility is required (or at least desired?) >> | for stable branches. >> | >> | While it's "nice-to-have" feature, I see no pressing need to MFC this >> | interface. >> >> I don't think so, perhaps I am wrong, but do we really want absolutely >> no *new* features on -STABLE branches? > > ISTR that in prior discussions on symbol versioning, the consensus > was that there's nothing wrong with adding new APIs in -STABLE > branches, but of course apps that use the new features won't be > backwards-compatible. There's nothing technically wrong with it in that it will work, but for minor features that provide low marginal utility, I'm not sure that it is warranted. I would rather see the bar raised for new features added to -stable branches. But I don't feel strongly enough one way or the other to request a backout. > By the way, one catch is that once you MFC symbols in the FBSD_1.1 > namespace, any new symbols in the same library need to go in > FBSD_1.2. We do guarantee that public namespaces do not change > across stable branches. This is important for API-checking tools > like appcert: even if you can't prevent problems like the one > described previously, at least you have some assurance as to which > versions of FreeBSD will run your app. 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. One side note - this commit does show the proper way to MFC a new symbol to a previous branch. That doesn't mean that it should have been done, just that it was done properly :-) -- DE