From owner-cvs-all@FreeBSD.ORG Fri Dec 14 15:12:55 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 E9ECF16A41B for ; Fri, 14 Dec 2007 15:12:54 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9A24A13C442 for ; Fri, 14 Dec 2007 15:12:54 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so583933nzf.13 for ; Fri, 14 Dec 2007 07:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=TpAQ3+GaDHRlDBmeV8RUILHoFoQAoZZrtY3OiMFES0U=; b=PvlfdBhhK/55CgeRwuxWTGhfmVdWKFAGrHv+ax20Ge3vnDiag8XcMHsIYUTqWq9F390IF5DJA82h/2kw5jQM4aQUBenmx3+FEacuSbE/JkIgmKRaVoJ0mh1L9GvfLam/Oll7gBjWoyg55vCyvVehPXJtw0wEWCbMy61LqE91w/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=BF915WCz3NR+owe34lSyWq1dFkAbMLxKBkXwR9SZpSQyIXnB7vFafe11MJTfG1FFoCuAq17jzSwALKsci0mUqPKYuLy9oILIRL7S/vYcTuavyHquDqcfNnjefJyX1ghTn08NOeUyCJ/2nlb0E+CjPg5NMxZaCSdeYwXSwZ5y0AU= Received: by 10.142.221.19 with SMTP id t19mr1507760wfg.62.1197645173034; Fri, 14 Dec 2007 07:12:53 -0800 (PST) Received: from kan.dnsalias.net ( [24.218.183.247]) by mx.google.com with ESMTPS id i35sm9063459wxd.2007.12.14.07.12.50 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2007 07:12:51 -0800 (PST) Date: Fri, 14 Dec 2007 10:12:43 -0500 From: Alexander Kabaev To: Daniel Eischen Message-ID: <20071214101243.65a0723f@kan.dnsalias.net> In-Reply-To: References: <200712140308.lBE38Ae7061160@repoman.freebsd.org> <20071213235617.2b554b60@kan.dnsalias.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/=k06e821ZesM+onE6ip4A3c"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: David Schultz , Yar Tikhiy , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/msun Symbol.map 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: Fri, 14 Dec 2007 15:12:55 -0000 --Sig_/=k06e821ZesM+onE6ip4A3c Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 14 Dec 2007 00:48:51 -0500 (EST) Daniel Eischen wrote: > On Thu, 13 Dec 2007, Alexander Kabaev wrote: >=20 > > On Fri, 14 Dec 2007 03:08:10 +0000 (UTC) > > David Schultz wrote: > > > >> das 2007-12-14 03:08:10 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> lib/msun Symbol.map > >> Log: > >> Typo in previous commit > >> > >> Revision Changes Path > >> 1.6 +2 -2 src/lib/msun/Symbol.map > >> > >> http://cvsweb.FreeBSD.org/src/lib/msun/Symbol.map.diff?r1=3D1.5&r2=3D1= .6 > > > > This is just wrong IMHO. New exported symbols should not be > > introduced carelessly and certainly not should be added to the same > > namespace that exists in 7.0. Either we add these to 7.0 before it > > releases, or they should go into their own section which will start > > collecting all new libc symbols to appear in 8.0. > > > > Daniel, Yar - what is your take on this? >=20 > I think we reached some sort of consensus that the namespace would be > bumped for every release...? So unless these get added to 7.0 before > it goes out the door, they should be put in a separate namespace. >=20 > On the other hand, newly added symbols don't break the ABI. I > don't think there is a technical reason why symbols can't be > added to FBSD_1.0 in -current; they can be easily backported > to 7.0. If you were to add them to FBSD_1.1 in -current, then > at a later time backport them to 7.0, then you would have to > create a new namespace (FBSD_1.1) in 7.0 in order to add them. > The only thing this buys you is being able to tell in what > version they originated. Perhaps that's reason enough? >=20 > At a minimum, we need to create one new namespace in each > release branched from -current when there is one or more > ABI changes from the prior release. Perhaps we should just > move to FBSD_1.1 now in 8-current just to make things easier. > When we go to 9-current, we move to FBSD_1.2, etc. If you > need to backport changes back to 7.x, then you also have to > create the matching version in 7.x. I think this was our understanding last time, but I wanted to check that I didn't forget anything. Adding symbols o FBSD_1.0 does not technically breaks ABI, but creates namespace that is a superset of one existing in 7.0. The 'classic' use of symbol versioning requires rtld to check all the namespace dependencies recorded for the binary, and the fact that namespace X exists in some library indicates that _all_ symbols from X are there and binary can run with this particular version of the library. Extending FBSD_1.0 breaks this. --=20 Alexander Kabaev --Sig_/=k06e821ZesM+onE6ip4A3c Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHYp1rQ6z1jMm+XZYRAix2AJ9VRzHXG53jsjhgtwbam9vxyt51HQCcCRPi fjnVoovUr4Wc7a+ybpMJki4= =OtjP -----END PGP SIGNATURE----- --Sig_/=k06e821ZesM+onE6ip4A3c--