Date: Mon, 27 Aug 2007 18:24:18 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <Pine.GSO.4.64.0708271814370.28508@sea.ntplx.net> In-Reply-To: <20070827221002.GS21352@comp.chem.msu.su> References: <200708270850.20904.jhb@freebsd.org> <20070827.141125.-1573947069.imp@bsdimp.com> <Pine.GSO.4.64.0708271648570.28508@sea.ntplx.net> <200708271715.21462.jhb@freebsd.org> <Pine.GSO.4.64.0708271719510.28508@sea.ntplx.net> <20070827221002.GS21352@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Aug 2007, Yar Tikhiy wrote:
> On Mon, Aug 27, 2007 at 05:38:08PM -0400, Daniel Eischen wrote:
>>
>> 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.
>
> I guess everything will work after changing pthread_mutex_t if either
> nothing calls pthread_mutex functions or compatibility shims for them
> are provided under FBSD_1.0. Is it correct?
Yes, though I was assuming that compat shims are added whenever
you change the ABI. For this example, we know that there are
a lot of applications that use pthread_mutex-related APIs, so
the appropriate compat shims would definitely be needed.
>> 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.
>
> Just to make things clear: if FBSD_1.0, FBSD_1.1, and FBSD_1.2 are
> already populated with some symbols and a symbol from FBSD_1.0
> undergoes an incompatible change, which version it should be promoted
> to, FBSD_1.1 or FBSD_1.2? AFAIK, technically either is possible.
Correct, you can add the new APIs to either FBSD_1.1 or FBSD_1.2,
and I do raise this question (as a TBD) in:
http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt
I would think that we would always use the latest version when
adding new ABI changes to -current. In release branches, MFCs
have to go the the same version from which they came in -current
(to maintain forward compatibility).
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708271814370.28508>