cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Daniel Eischen]

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