[procps] Re: new library
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Mon, 29 Jun 2015 01:40:18 -0500
On Jun 26, 2015, at 7:48 AM, Craig Small <csmall-procps@xxxxxxxxxx> wrote:
I'm hoping to get all the non-process (e.g nothing under /proc/<PID>/*)
stuff done, then decide wether or not to have a go at the PID related
things. They're a bit trickier as there are a lot of loops; there is
only one /proc/stat but many /proc/<PID>/stat
Hi Craig,
In the hope of contributing to the above goal, the attached tarball contains my
library and top patches.
In tried (really, I did) to limit the scope of my meddling. But when tabs are
removed and two identifiers changed, those git insertions/deletions really pile
up. There are more changes that could have been made, revealed with a -Wall
make, but I’ll leave those up to others.
Anyway, there’s yet one more patch I’m still working on for
Documentation/CodingStyle. I’ll plead against tab characters, codify the
formatting and naming conventions you employed and try to justify some of the
damage I did. Don’t hold your breath for that one though.
I've also generally used a if then else chain to load the variables;
there were a variety of methods but the (admittedly simple) profiling
I've done the if,then,else seemed to be the fastest. It's also really
simple to debug.
Generally almost all the functions:
* load, or rewind, a file
* read the whole file into a buffer
* scan for keywords
* try to see if there is a corresponding variable for keyword
* if yes, add it
* find next keyword and repeat
The corresponding variable match is the bit I'm talking about.
The btree code to me seems inefficient, except if you have a big
search space, which we don't.
I agree with you about the bsearch, but one of my patches adds an extra step to
a strcmp series. In /proc/meminfo there are many variables we don’t care
about. So I added a quick switch/case on the first letter bringing the strcmp
call exposure down from a maximum of 14 to 1-4. That two phase approach may be
applicable to other /proc files as well, especially as the number of ignored
variables increases.
My readstat modifications were extensive. The meminfo 'chaining' approach was
added there for other programs to use (and for symmetry) but it wasn’t a good
fit for top’s cpu/numa needs. So I took an entirely different approach while
still striving for that opaqueness goal.
Basically it involves the standard new, read and get functions you pioneered.
But at get time, rather than passing an enum or a chained results struct, the
caller supplies one of two new structures which the library then fills with
jiff counts. And there is a builtin new/old history capability that callers
can exploit. It comes with virtually no library cost whatsoever (just 2 memcpy
calls).
As always I’ll welcome any comments and will continue testing/stressing newlib
here in Minnesota.
Regards,
Jim
Attachment:
for-newlib-only.tgz
Description: Binary data
Other related posts:
