Harvard Business School of Echec - Tag - linux - Commentaires

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Fri, 25 Apr 2008 21:10:11 +0200

err, yes, you need to implement PSS in all other platforms if you want to add it and not leave it empty for non-linux. Obviously. But you don't need to implement anything else already done yet again with the suggestion in comment #8...

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Wed, 23 Apr 2008 11:11:02 +0200

Whenever i add a new functionnality (which is implemented as 3/4 functions), it has to be ported on linux, the 2 BSD arch and eventually solaris, darwin or aix. I can't do all these ports because of a lack of time/interest. So adding a new function for a single guint64 is too much work/breakage.

I was looking for alternatives where i would be able to do all the work myself:
- breaking the ABI moves all the work to distro packagers
- breaking the API would let me submit trivial patches to upstreams

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 23:22:30 +0200

Benoît> "Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release)."

How about adding the PSS support to the existing functions, but afterwards renaming glibtop_get_proc_mem to the new name, while adding a compatibility wrapper of the old name (keeping API and ABI in effect) that constructs the old style struct out of the results it gets from the new one that has more data - should be just some struct field copying and throwing away the bigger struct before returning the copied (deprecated) compatibility one from glibtop_get_proc_mem

ABI vs. API compatibility - Bronson

Bronson — Tue, 22 Apr 2008 21:32:40 +0200

I gotta agree with Rob... Leave this code alone, deprecate it, and just add a new call that takes a selector to tell what value to return.

Otherwise, you'll have to figure out hack upon hack upon hack every time you want to make this sort of change in the future. And, given kernel development, it won't be long before you'll need to extend it again...

ABI vs. API compatibility - James Henstridge

James Henstridge — Tue, 22 Apr 2008 17:22:04 +0200

If you decide to break the API, one option would be to add a "version" field to the start of the struct. Require the caller to fill it in before calling glibtop_get_proc_mem() so you can tell how big the caller thinks the struct is. Include the current version as a #define in the header so the caller can use it to initialise the structure to the right version.

If you need to expand the struct in the future, increment the version number and add new fields to the end. Then make glibtop_get_proc_mem() only fill in the fields if the version number is appropriate.

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Tue, 22 Apr 2008 16:04:37 +0200

Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release).

Storing pointers is not an option because the struct may be marshalled across a pipe. And the marshalling code is already terribly broken.

Adding reserved members is very hard when you don't want to bloat your struct. I've already provisioned glibtop_cpu for 32 CPU, that makes sizeof ~ 2KiB.

ABI vs. API compatibility - Jeff Licquia

Jeff Licquia — Tue, 22 Apr 2008 15:04:22 +0200

You could start using symbol versioning, and provide both.

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 14:20:00 +0200

Looks like that duplicated guint64 could fit a pointer that could point to a new struct with more padding. However, I'm wondering what's the point of this public structure - wouldn't separate function APIs for a set of these be more ABI proof? if that's a good idea, could just not expose PSS in that struct at all and introduce some new API for this, say glibtop_proc_get_pss. Then again, I assume it's all retrieved in one go and that would reduce efficiency when one needs to call get_pss, get_rss and so on in a row?
If you need to stick with a struct, it might be a good idea to at some point introduce a new one that has some padding available for future expansion and a new function, say glibtop_get_proc_mem2 (yes, need a better name) that returns it, having library users that need PSS information convert to the API and depend on the new libgtop version.
Sorry, just thinking out loud, maybe something useful

ABI vs. API compatibility - Rob

Rob — Tue, 22 Apr 2008 14:06:55 +0200

Well, all these options are ABI breaking - the 'break the API' options also break ABI, just subtly. which is worse, as its not obvious to developers or package maintainers that something has changed.
IMHO, the best option is to deprecate glibtop_get_proc_mem and add a new function (say glibtop_get_process_usage or such) that takes a pid and an enum value for which field to return.

ABI vs. API compatibility - Murray Cumming

Murray Cumming — Tue, 22 Apr 2008 14:03:37 +0200

If it's this simple then you can just add a new function that returns a new struct, and deprecate (not break) the old one.

loc-srv - rbx

rbx — Tue, 11 Sep 2007 00:34:50 +0200

It' would be nice to have ruby support in Nautilus, Gedit, Totem plugins..