[procps] new top fields, library implications
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Thu, 16 Feb 2012 11:41:55 -0600
Hi Craig, et.al.
As I was going through the Debian bug reports, I came upon this 11 year old
wishlist item:
#84992, should have (better) column for page faults
Erno Kuusela's request was for a more meaningful alternative to the total
accumulated 'nMaj' major page fault counts. Of course, our top also provides
for 'nMin' minor page fault counts, something not possible under the former 26
field limit.
As new fields in top, I've implemented 'vMaj' and 'vMin' for the page fault
count deltas since the last update . But I need help and advice on a couple of
issues.
1. I had to add new fields to the proc_t (maj_delta, min_delta), similar to
pcpu and I placed them adjacent to that field. These three fields are not
valued by readproc, rather they serve as placeholders for user data. But there
might be a better way.
Perhaps the current such fields should be eliminated in favor of more
generalized and expanded identifiers such as:
user_address_1, etc.
user_long_1, user_long_2, etc.
user_int_1, user_int_2, user_int_3, etc.
Then callers could provide their own #define aliases following the #include of
readproc.h. Moreover, if all such user fields were moved to the end of the
proc_t, future binary compatibility *might* be maintained even if they were
expanded. I say 'might' since some code somewhere could also have a
sizeof(proc_t) dependencies.
2. The library API remains the same but my changes have broken the ABI. I
could avoid the obvious breakage by moving my new fields to the end of the
proc_t. However, this wouldn't help with the size issue and, besides, it's
nice to keep these related (unvalued by readproc) fields together.
In any case, I'm not at all sure how to handle such ABI breakage under our
current library and symbol versioning even with the help of this:
http://sourceware.org/autobook/autobook/autobook_91.html.
My instinct is to bump LIBprocps_CURRENT=1 in proc/Makefile.am so we end up
with 1:0:0. But should we also add the '-release' flag to
libprocps_la_LDFLAGS? Additionally, how is libprocps.sym impacted, if at all,
since the proc_t fields are not directly referenced as symbols? Maybe a new
LIBprocps_CURRENT takes care of that.
Anyway, do you guys think these two new fields are worthwhile and if so how do
we deal with any needed library changes?
Regards,
Jim
Other related posts:
