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

[Daniel Eischen]

On Mon, 27 Aug 2007, John Baldwin wrote:

> On Monday 27 August 2007 04:55:31 pm Daniel Eischen wrote:
>> On Mon, 27 Aug 2007, M. Warner Losh wrote:
>>
>>> In message: <200708271529.42264.jhb at freebsd.org>
>>>            John Baldwin <jhb at freebsd.org> writes:
>>> : And yes, I do think it's ok for -current to have rougher edges.  After
> all, we
>>> : aren't really trying to get people running -current on production
> systems.
>>>
>>> I think it is OK for -current to have rougher edges.  I don't think it
>>> is OK to require -current to have rougher edges.
>>
>> I think we can agree on that!  I also think there is some confusion
>> over whether adding ABI changes to an existing symbol version would
>> force us to rebuild ports.  It doesn't.  Once symbol versioning is
>> released in 7.0, we can create a new version (FBSD_1.1, or add to
>> the existing FBSD_1.1 depending on how the FTS stuff goes) and add
>> all the (non-overlapping) ABI changes we want to it _without_ having
>> to rebuild ports.  This is a tremendous advantage over -current as
>> it is today.
>
> So you want to just bump the version everytime a change happens in HEAD?

No, I don't see how you get that from what I said...

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

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.

-- 
DE