Date: Mon, 27 Aug 2007 13:21:06 -0400 From: John Baldwin <jhb@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Warner Losh <imp@bsdimp.com>, yar@comp.chem.msu.su Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <200708271321.08014.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.64.0708271304390.28508@sea.ntplx.net> References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <200708271041.23205.jhb@freebsd.org> <Pine.GSO.4.64.0708271304390.28508@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 27 August 2007 01:10:14 pm Daniel Eischen wrote: > On Mon, 27 Aug 2007, John Baldwin wrote: > > > > Perhaps a more useful discussion would be how can we use symbol versioning > > sanely to support this in the future? The fbsd.hack idea could work, but > > it doesn't work in this case because the existing binaries are already > > linked. One suggestion that could start with 8.0 could be this: > > > > - when bumping the version for a symbol in HEAD, instead of going from > > fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0. You > > can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent > > changes > > - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0 > > symbol versions for the current versions of all the bumped symbols, and > > remove all the fbsd-current-* versions and compat shims before the > > release (before the RELENG_X+1_0 branch in fact). The rule there being > > that no release should ever ship with visible fbsd-current-* symbol > > versions. > > I don't think you need intermediate symbol versions, one should be > sufficient. The problem would only arise if you make an ABI change > to a function or set of functions that have already had an ABI change > in the current version. For example, if there were a function > ftsfwrite(FTS, FILE *, ...), and you make the version bump from > FBSD_1.0 to FBSD_1.1 when FTS changes, then if FILE changes, you > need to bump FBSD_1.1 to FBSD_1.2. If there are no overlapping > changes in the ABI, you can continue to add newly changed symbols > to the current version (in this case FBSD_1.1). Actually, what we have now with fts(3) is exactly this: two versions of the symbols that wish to be called fbsd_1.0. By using a late binding of the "official" fbsd_X.0 version we can avoid that. It also provides a way to delineate ABI changes that aren't visible to releases and -stable branches. They will exist in HEAD with only having a fbsd-current symbol, so they can be axed from HEAD safely. > How may times have we ever had overlapping ABI changes in the past? > Have we ever? It's not worth fiddling with intermediate symbols, > because with that method you're still forcing -current users to > rebuild everything just before or after RELEASE to get the final > symbols (when the intermediates are removed). If there are no > overlapping ABI changes, then no one has to rebuild any ports. You don't have to remove the compat shims from HEAD right away. Remember, release is on a _branch_: RELENG_X. You remove the compat shims from the branch before the release, but you can use discretion as to when you actually remove them from HEAD. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708271321.08014.jhb>