Is the FreeBSD ABI compatibility policy documented anywhere

[Stef Walter]

It seems that FreeBSD has an ABI compatibility policy where major
versions remain ABI and API compatible throughout minor point versions.
That is to say that the kernel interfaces and libraries for (eg)
7-STABLE, 7.1-RELEASE, 7.2-RELEASE are not supposed to change.

Is this a policy of the project? If so, is it documented anywhere? Or is
it just a convention?

Cheers,

Stef

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Julian Elischer]

Stef Walter wrote:
> It seems that FreeBSD has an ABI compatibility policy where major
> versions remain ABI and API compatible throughout minor point versions.
> That is to say that the kernel interfaces and libraries for (eg)
> 7-STABLE, 7.1-RELEASE, 7.2-RELEASE are not supposed to change.
>
> Is this a policy of the project? If so, is it documented anywhere? Or is
> it just a convention?

It is a policy of the project but I don't think our policies are
written down as such. I think you will find it referenced in
many places in a sideways manner rather than directly.

Possibly in the developer handbook

>
> Cheers,
>
> Stef
>
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Bruce Cran]

On Thu, 24 Sep 2009 14:00:04 -0700
Julian Elischer <julian@...> wrote:

> Stef Walter wrote:
> > It seems that FreeBSD has an ABI compatibility policy where major
> > versions remain ABI and API compatible throughout minor point
> > versions. That is to say that the kernel interfaces and libraries
> > for (eg) 7-STABLE, 7.1-RELEASE, 7.2-RELEASE are not supposed to
> > change.
> >
> > Is this a policy of the project? If so, is it documented anywhere?
> > Or is it just a convention?
>
> It is a policy of the project but I don't think our policies are
> written down as such. I think you will find it referenced in
> many places in a sideways manner rather than directly.
>
> Possibly in the developer handbook

The only place I found it directly referenced was in
http://wiki.freebsd.org/VendorInformation

--
Bruce Cran
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Simon L. Nielsen]

On 2009.09.24 15:26:34 -0500, Stef Walter wrote:
> It seems that FreeBSD has an ABI compatibility policy where major
> versions remain ABI and API compatible throughout minor point versions.
> That is to say that the kernel interfaces and libraries for (eg)
> 7-STABLE, 7.1-RELEASE, 7.2-RELEASE are not supposed to change.

It's not entirely that simple.  The ABI on a stable branch like 7.x
should be backward compatible, but there isn't a guarantee of forward
compatibility.  IE, 7.0 binary should be able to run on 7.x, but a 7.2
binary might not run on 7.0.  It should be more or less the same with
the API's.

PS. do note that there is no 100% guarantee.  At times the defacto
policy might be violated if there are very good reasons for doing so.
This would e.g. an important fix for something where the changed ABI,
more likely K(kernel)BI, change should affect few people and the
change is required for fixing some important bug.

> Is this a policy of the project? If so, is it documented anywhere? Or is
> it just a convention?

I don't remember seeing it ever documented, just discussed.  What I
wrote above is also just my understanding of curreny defact policy.

--
Simon L. Nielsen
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Dag-Erling Smørgrav]

"Simon L. Nielsen" <simon@...> writes:
> It's not entirely that simple.  The ABI on a stable branch like 7.x
> should be backward compatible, but there isn't a guarantee of forward
> compatibility.  IE, 7.0 binary should be able to run on 7.x, but a 7.2
> binary might not run on 7.0.  It should be more or less the same with
> the API's.
>
> PS. do note that there is no 100% guarantee.

Correct, but we're getting closer to that now that we have symbol
versioning - although we won't reach 100% until we have versioned
symbols in *all* libraries, which is currently not the case.  Even then,
a developer might break the ABI by mistake, but hopefully we'd catch
that before it made it into a release.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alex Goncharov-4]

,--- You/Dag-Erling (Sat, 10 Oct 2009 19:11:50 +0200) ----*
| "Simon L. Nielsen" <simon@...> writes:
| > It's not entirely that simple.  The ABI on a stable branch like 7.x
| > should be backward compatible, but there isn't a guarantee of forward
| > compatibility.  IE, 7.0 binary should be able to run on 7.x, but a 7.2
| > binary might not run on 7.0.  It should be more or less the same with
| > the API's.
|
| Correct, but we're getting closer to that now that we have symbol
| versioning - although we won't reach 100% until we have versioned
| symbols in *all* libraries, which is currently not the case.  Even then,
| a developer might break the ABI by mistake, but hopefully we'd catch
| that before it made it into a release.

It's important to note that symbol compatibility is not the whole
thing -- the behaviour on exceptions may be equally important to some
applications.  E.g. CMUCL code has to handle different ways to notify
of memory protection failures this way:

    #if __FreeBSD_version < 700004
    #define PROTECTION_VIOLATION_SIGNAL SIGBUS
    #define PROTECTION_VIOLATION_CODE BUS_PAGE_FAULT
    #else
    #define PROTECTION_VIOLATION_SIGNAL SIGSEGV
    #define PROTECTION_VIOLATION_CODE SEGV_ACCERR
    #endif

A CMUCL binary built on a pre-7.1 (?) release of FreeBSD, will crash
almost immediately when run on 7.1 (well, "if memory serves").

-- Alex -- alex-goncharov@... --
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Kostik Belousov]

On Sat, Oct 10, 2009 at 02:11:07PM -0400, Alex Goncharov wrote:

> ,--- You/Dag-Erling (Sat, 10 Oct 2009 19:11:50 +0200) ----*
> | "Simon L. Nielsen" <simon@...> writes:
> | > It's not entirely that simple.  The ABI on a stable branch like 7.x
> | > should be backward compatible, but there isn't a guarantee of forward
> | > compatibility.  IE, 7.0 binary should be able to run on 7.x, but a 7.2
> | > binary might not run on 7.0.  It should be more or less the same with
> | > the API's.
> |
> | Correct, but we're getting closer to that now that we have symbol
> | versioning - although we won't reach 100% until we have versioned
> | symbols in *all* libraries, which is currently not the case.  Even then,
> | a developer might break the ABI by mistake, but hopefully we'd catch
> | that before it made it into a release.
>
> It's important to note that symbol compatibility is not the whole
> thing -- the behaviour on exceptions may be equally important to some
> applications.  E.g. CMUCL code has to handle different ways to notify
> of memory protection failures this way:
>
>     #if __FreeBSD_version < 700004
>     #define PROTECTION_VIOLATION_SIGNAL SIGBUS
>     #define PROTECTION_VIOLATION_CODE BUS_PAGE_FAULT
>     #else
>     #define PROTECTION_VIOLATION_SIGNAL SIGSEGV
>     #define PROTECTION_VIOLATION_CODE SEGV_ACCERR
>     #endif
>
> A CMUCL binary built on a pre-7.1 (?) release of FreeBSD, will crash
> almost immediately when run on 7.1 (well, "if memory serves").

This has been an issue for 7.0, and it was explicitely handled, see r174254.

[Alex Goncharov-4]

,--- You/Kostik (Sat, 10 Oct 2009 21:20:48 +0300) ----*
| > A CMUCL binary built on a pre-7.1 (?) release of FreeBSD, will crash
| > almost immediately when run on 7.1 (well, "if memory serves").
|
| This has been an issue for 7.0, and it was explicitely handled, see r174254.

I know it was (I was the one who first ran into the problem, way back
then).

My point here was to state that the behavior on signals is almost as
important as symbols' compatibility.

As for "it was", see this few-days-old thread:

  http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/287d1a57226f0cda/a6805cf10ca0cab9?q=cmucl&lnk=nl&

  I found an even easier way to crash CMUCL 19c/19f on FreeBSD 7.1

where the last message was posted today.  Although most messages there
are totally unrelated to CMUCL, FreeBSD (in fact, almost anything
relevant), somebody, somewhere still hit the issue a few days ago (I
am not inclined to analyze his environment, frankly).

The question, "Will a FreeBSD 7.2 (e.g.) build run all right on
FreeBSD 8.0 (e.g.)?", is often asked, and I think it is impossible to
give any guarantees -- the best one can realistically say, is,
"probably" (with compatibility libraries, in some case).

At least, I don't give any assurances for the binaries I upload to
http://common-lisp.net/project/cmucl/downloads: I build against the
latest code on a few branches of FreeBSD (RELENG and CURRENT) -- and
if a 7.2 build runs for you on 7.1 and/or 8.0, you are in luck (and I
do expect this), but it may not, and who will tell you it will, without
trying?

-- Alex -- alex-goncharov@... --
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."