Re: [Nagios-devel] Object structure change
Posted: Tue Feb 26, 2013 11:06 am
On 02/25/2013 07:11 PM, Ton Voon wrote:
> Hi,
>
> Looking through recent commits, I came across 2601, which is a port
> of 2600, to fix a downtime issue.
>
> There is a change to downtime.h to add a new attribute to the
> downtime object.
>
> Am I right in saying that this is a object structure change and thus
> will affect the binary compatibility of all broker modules? If so,
> this is a problem for Nagios 4 which is in a structure freeze before
> release, but more seriously it is a problem in the Nagios 3.4 branch
> which will silently break lots of broker modules.
>
It's an ABI incompatibility, so it requires a recompile of affected
modules. No modules use the modified function calls, so for that part
it doesn't matter in practical terms, although it's academically
horribly (which is to say; It only matters if you're interested in
intellectual masturbation). Nagios 3 with the patch should really be
released as 3.5 though. For Nagios 4 it's ok to make this change
(although I'm not very happy about it).
On a side-note, the downtime handling needs to be rewritten more or
less completely. I've started it, but the old code has to remain in
place (as a shim, preferrably) until 5.0 to retain api compatibility.
To clarify, here are the "rules" which we try to adhere to:
API change (requires major release):
* remove things from structs
* remove or modify existing functions
* remove existing types
* rename existing types without backwards compatibility hacks
("#define comment nagios_comment" is the compat hack)
ABI change (requires minor release and module recompilation):
* add stuff to structs
* reorder structs
API addendum (requires API minor-version extension marker):
* add new types
* add new API's
* add functions to API's
Shimming (requires nothing at all):
* Add new API
* Rewrite old API in ABI-compatible way to front the new API
* Use new API in core code
Normally, ABI change and API addendum go hand in hand when doing
optimizations, and sometimes when doing bugfixes.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> Hi,
>
> Looking through recent commits, I came across 2601, which is a port
> of 2600, to fix a downtime issue.
>
> There is a change to downtime.h to add a new attribute to the
> downtime object.
>
> Am I right in saying that this is a object structure change and thus
> will affect the binary compatibility of all broker modules? If so,
> this is a problem for Nagios 4 which is in a structure freeze before
> release, but more seriously it is a problem in the Nagios 3.4 branch
> which will silently break lots of broker modules.
>
It's an ABI incompatibility, so it requires a recompile of affected
modules. No modules use the modified function calls, so for that part
it doesn't matter in practical terms, although it's academically
horribly (which is to say; It only matters if you're interested in
intellectual masturbation). Nagios 3 with the patch should really be
released as 3.5 though. For Nagios 4 it's ok to make this change
(although I'm not very happy about it).
On a side-note, the downtime handling needs to be rewritten more or
less completely. I've started it, but the old code has to remain in
place (as a shim, preferrably) until 5.0 to retain api compatibility.
To clarify, here are the "rules" which we try to adhere to:
API change (requires major release):
* remove things from structs
* remove or modify existing functions
* remove existing types
* rename existing types without backwards compatibility hacks
("#define comment nagios_comment" is the compat hack)
ABI change (requires minor release and module recompilation):
* add stuff to structs
* reorder structs
API addendum (requires API minor-version extension marker):
* add new types
* add new API's
* add functions to API's
Shimming (requires nothing at all):
* Add new API
* Rewrite old API in ABI-compatible way to front the new API
* Use new API in core code
Normally, ABI change and API addendum go hand in hand when doing
optimizations, and sometimes when doing bugfixes.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]