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

[Yar Tikhiy]

On Mon, Aug 27, 2007 at 05:38:08PM -0400, Daniel Eischen wrote:
> On Mon, 27 Aug 2007, John Baldwin wrote:
> >That
> >seems to contradict your earlier changes as you are now saying use 1.1 for
> >fts(3), etc.  Also since you mentioned MFC'ing one ABI (say 1.5) but not
> >others (1.2-1.4), that implies each change in HEAD has its own first-level
> >version?
> 
> FBSD_1.1 should get us out a few years.  Unless you have an ABI change
> that is _already_ in FBSD_1.1, you don't have to create a new version.
> 
> 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?

> 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.

-- 
Yar