[procps] Re: top: NUMA node CPU utilization support
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Tue, 11 Jun 2013 10:40:17 -0500
On Jun 11, 2013, at 7:09 AM, Jaromir Capik <jcapik@xxxxxxxxxx> wrote:
> I was thinking about the best way, how to automate this.
> Your previous approach gives a sense. The probability
> of future changes in the two called functions is lower
> than probability of increasing the soname version.
> That means, the solution counting with symlink can
> correctly work much longer than any solution with
> hardcoded versions. Maybe we could use autotools for
> checking the function prototypes (numa.h) and if they
> are compatible, we could resolve the libnuma.so symlink
> to get the versioned soname.
> Does anyone have a better idea how to fight with this?
Jaromir,
The original approach would have broken top if ever the API for the 2 libnuma
functions had changed. Under those conditions, the user had no recourse
whatsoever except to avoid the '2' and '3' keys (and likely abend).
The solution we currently have in place can correctly work forever, since
version 1 of libnuma can coexist with any future version. If ever libnuma.so.1
disappeared, the '2' and '3' keys simply become inoperative. Whether or not
that specific library is present is completely under user control.
Jim
Other related posts:
