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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
