Hi!
I've been looking at tagging new versions of our libraries. I know Pau in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't find any instructions about it, nor has it been automatized it seems.
I've now started with this and have a setup that we can run nightly to generate ABI/API compatibility reports.
There are unfortunately some issues in libosmogsm:
http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12....
related to LCLS changes that (I believe) were mostly introduced by Max.
gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine.
gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we sure there were no users of the function? The old signature was part of the previous release!
In libosmocore we have some problem related to 'struct log_target': http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12.... I suppose this is "only" ABI breakage but not API breakage and hence a new libversion can rescue us?
In libgtp we also have changes requiring a libveersion change: http://people.osmocom.org/laforge/abi-report/compat_report/osmo-ggsn/1.2.2/c...
Apart from that, it looks quite fine. libosmo-sigtran has two new symbols, but remains fully backwwards compatible: http://people.osmocom.org/laforge/abi-report/compat_report/libosmo-sccp/0.10...
Feel free to comment. The most important part is to get the libosmocore/LCLS questions resolved.
Regards, Harald
Hi.
19.01.19 00:24, Harald Welte пишет:
I've been looking at tagging new versions of our libraries. I know Pau in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't find any instructions about it, nor has it been automatized it seems.
Maybe we could integrate it into 'make release' helper of libosmocore?
gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine.
In general, is there particular reason why we wouldn't want to bump soversion when making new release? Unless it's a minor bugfix release of course but so far we haven't bothered with those AFAIK.
I've tried to add some general notes to https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release but there's still plenty of room for improvement. In general I thought that releasing new library version is the perfect opportunity to update soversion as well.
gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we sure there were no users of the function?
The only user I know of is OsmoBSC v1.3.0 which is part of several repositories according to https://repology.org/metapackage/osmo-bsc/versions - shall we change the function name or bumping soversion will take care of ABI incompatibility?
From reading old paper by Ulrich Drepper [1] the latter seems to be the case. If I'm missing something than we should document it by expanding our release wiki [2].
In libosmocore we have some problem related to 'struct log_target': http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12.... I suppose this is "only" ABI breakage but not API breakage and hence a new libversion can rescue us?
I'm confused by this: I thought that API breakage is taken care by new release version while ABI breakage is handle with new libversion?
Feel free to comment. The most important part is to get the libosmocore/LCLS questions resolved.
Let me know if I should make a patch which will covert ABI breakage into new API by adding gsm0808_create_lcls_conn_ctrl2() for example.
[1] https://www.akkadia.org/drepper/dsohowto.pdf
[2] https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
Hi Max,
On Sat, Jan 19, 2019 at 04:56:43PM +0100, Max wrote:
19.01.19 00:24, Harald Welte пишет:
I've been looking at tagging new versions of our libraries. I know Pau in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't find any instructions about it, nor has it been automatized it seems.
Maybe we could integrate it into 'make release' helper of libosmocore?
I don't see how that would work. You have to analyze *befoer* you do 'make release'.
Instead, the plan is to simply run the job to generate the reports by a cronjob every night, so that we have daily up-to-date reports of how 'current' differs from the last tagged version of each library.
gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine.
In general, is there particular reason why we wouldn't want to bump soversion when making new release? Unless it's a minor bugfix release of course but so far we haven't bothered with those AFAIK.
Compatibility. We don't want to force people to rebuild all their binaries just because somebody thought an enum was better than an uint8_t as a function argument.
Sure, if there are important reasons to break ABI, do it. But don't do it without a good reason.
gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we sure there were no users of the function?
The only user I know of is OsmoBSC v1.3.0 which is part of several repositories according to https://repology.org/metapackage/osmo-bsc/versions
- shall we change the function name or bumping soversion will take care of
ABI incompatibility?
The problem here is not ABI compatibility, but API compatibility. Sure, we can (and have to) bump the LIBVERSION/soversion. But then if you want to build the old application (OsmoBSC v1.3.0 in your example) against a new libosmocore it will fail. This is absolutely unacceptable.
However, I cannot find any reference to gsm0808_create_lcls_conn_ctrl() in osmo-bsc, neither in 1.3.0 nor in master - nor in the entire commit log. I guess we were really lucky this time.
But still, I don't get all this "changing function signatures for no real gain" game.
The old signature accepted pointers to the structure, and you had to change it so the structures are passed on the stack. Where's the gain in that? You camn do it one way or another. Why even only risk breaking some unknown 3rd party program out there for no apparent benefit at all?
I'm confused by this: I thought that API breakage is taken care by new release version while ABI breakage is handle with new libversion?
API breakage is never "taken care of". We cannot break APIs, as a general rule. Old applications should always work if recompiled against new libraries. There are exceptions in situations where e.g. a symbol was accidentially exported which was only meant to be used inside the library. Then it's fine to remove it. But changing the signature of a function *after* it has been part of a tagged version is *not* acceptable.
Let me know if I should make a patch which will covert ABI breakage into new API by adding gsm0808_create_lcls_conn_ctrl2() for example.
If at all, I would simply revert the change. But it seems we can do without.
Regards, Harald
gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine.
In general, is there particular reason why we wouldn't want to bump soversion when making new release? Unless it's a minor bugfix release of course but so far we haven't bothered with those AFAIK.
Compatibility. We don't want to force people to rebuild all their binaries just because somebody thought an enum was better than an uint8_t as a function argument.
Sure, if there are important reasons to break ABI, do it. But don't do it without a good reason.
I wish C had enum types with explicit size :/
IMO let's revert back to uint8_t and put the enum type in the API doc.
~N
On Sat, Jan 19, 2019 at 12:24:32AM +0100, Harald Welte wrote:
In libosmocore we have some problem related to 'struct log_target': http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12.... I suppose this is "only" ABI breakage but not API breakage and hence a new libversion can rescue us?
A new member added to the end of the struct. Since all log targets should be allocated by log_target_create(), in practice it isn't even an ABI breakage? We just pass log_target* on the ABI, right?
~N
-
Harald Welte -
Max -
Neels Hofmeyr