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

[M. Warner Losh]

In message: <Pine.GSO.4.64.0708272127371.28508 at sea.ntplx.net>
            Daniel Eischen <deischen at freebsd.org> writes:
: On Tue, 28 Aug 2007, Yar Tikhiy wrote:
: >
: > Example: Assume we released 7.0-R with all symbols at FBSD_1.0.
: > Before the 8.0 release cycle starts, struct FTS and struct FILE
: > change, perhaps a few times each, thus affecting the fts(3) and
: > stdio(3) global symbols.  At the very first change to a symbol or
: > their group, its 7.0-R variant is preserved at FBSD_1.0 and its
: > default version becomes FBSD_1.1.  Later changes to the current
: > variant of that symbol don't affect its version.  Consequently,
: > 8.0-R is released with the new fts(3) and stdio(3) symbols at
: > FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols
: > still at FBSD_1.0 because they are unchanged.  Let's note that
: > CURRENT users had to rebuild ports depending on fts(3) or stdio(3)
: > _each time_ an ABI component changed.
: 
: I think you're a little confused here.  CURRENT users did NOT have
: to rebuild ports when fts(3) or stdio(3) ABIs changed.  They
: would only have to rebuild if one of these ABIs changed _more
: than once between releases_.  That hasn't ever happened to my
: knowledge in the past, and it really shouldn't happen as long
: as things are tested and reviewed properly.

One of the reasons that it hasn't happened before is that we forced
people who tried to make, or proposed making, such changes to make
them in a compatible sort of way.  We have all kinds of ugliness in
and around FILE to try, alas in vain, to be compatible.  One of the
reasons people would like to see symbol versioning is to make it
easier to change the size of different structures because we have
stood on our heads in the past to not change sizes.

I'm concerned that the empirical evidence from the past might not be a
good thing to base our future plans upon.  We knew we had sucky tools
to deal with binary incompatibility in the past, so we stood on our
heads to not make too many binary incompatible changes.  With that
limitation gone, I think the likelihood is large we will see multiple
ABI changes between major releases on something.  Especially since it
happens when structures change size and there are many functions that
take pointers to multiple structures...

Warner