1. 16 May, 2019 3 commits
    • jim warner's avatar
      library: remove useless code for 2 'stacks_fetch' guys · 22a3bcbd
      jim warner authored
      These changes are an outgrowth of the research/testing
      behind the previous commit. There is no commingling of
      select/reap stacks in interfaces beyond the <pids> api
      since there's no need to support any 'reset' function.
      However, those <pids> changes prompted a review of all
      interfaces offering that 'stacks_fetch' function, thus
      revealing 2 instances of useless logic/wasted efforts.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: tweak support for get/select/reap, <PIDS> api · f87fc7dc
      jim warner authored
      When the <pids> api was refactored in the commit shown
      below, one objective was enabling the simultaneous use
      of 'get' & 'select/reap' functions. Unlike other 'get'
      functions, this <pids> 'get' acts as an iterator where
      successive calls will return successive tasks/threads.
      However, that goal wasn't quite met since a stack used
      by 'get' was commingled with the 'select/reap' stacks.
      Such commingling supported the 'reset' function, again
      a provision which was unique to this <pids> interface.
      Unfortunately, some poor assumptions in 'stacks_fetch'
      produced a SEGV whenever 'reap/select' followed 'get'.
      Thus, this patch addresses those issues and guarantees
      such commingled stacks (extents) will be accommodated.
      . standardize portions of interface, <PIDS> api
      commit 9ebadc14Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: correct 'vectorized' string logic, <PIDS> api · a9bfb186
      jim warner authored
      The commit referenced below addressed (some) anomalies
      surrounding 'strv' pointers. However, there remained a
      couple quirks involving a potential NULL return value.
      Any NULL values returned from the old library readproc
      guys would cause no real harm for newlib. But they did
      produce the misleading "[ duplicate ENUM_ID ]" result.
      The following all represent potential NULL results and
      suggest shortcomings in testing of that earlier patch.
      . kernel threads do not have cgroup, cmdline & environ
      . even if present environ could require root to access
      So, this patch reverts a portion of the earlier commit
      and ensures when some vectored string is not available
      a traditional dash ('-') is the 'strv' returned value.
      [ and we'll also correct one typo in the header file ]
      . eliminated a final potential NULL, <PIDS> api
      commit 09503dc5Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
  2. 26 Mar, 2019 6 commits
    • jim warner's avatar
    • jim warner's avatar
      library: refactored some header file items and origins · 6671a3a8
      jim warner authored
      This commit is intended as a refinement of the patches
      mentioned below, where origins/sources of newlib items
      were added to the header files for user documentation.
      However, if those additions are to be truly effective,
      along with kernel documentation (where available), the
      following prerequisites must also have been satisfied:
      . our identifiers closely align with linux field names
      . our derived items are documented or self-documenting
      Satisfying those prerequisites prompted this patch and
      for these changes, kernel sources were emphasized over
      available documentation (shame on me, it should always
      have been so). And, while some 'new' fields were found
      to be conditional, they were included unconditionally.
      These changes appear more extensive than they actually
      need be since I have attempted to enforce some spacing
      conventions. So, I've summarize the significant things
      in the sections that follow. For a proper perspective,
      use: 'git diff --ignore-space-change' (good as alias).
      ___________________________________________ <PIDS> api
      This api is unique in that there exists many different
      file/directory origins subordinate to /proc/<pid>. And
      our item identifiers are sometimes coerced so as to be
      able to group related or similar enumerators together.
      So, users needed more help relating our identifiers to
      an actual documented field. Thus, we will now also add
      the field names as with 'stat: delayacct_blkio_ticks'.
      Each item ending with a '_C' now consistently includes
      both the parent's count/time plus waited for children.
      That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
      since its original name is an implementation artifact.
      ___________________________________________ <STAT> api
      The only api change was to correct a typo ('dervied').
      _________________________________________ <VMSTAT> api
      Even ignoring white space, this interface received the
      largest number of changes. Mostly, this was because of
      deficiencies in the proc(5) documentation. Recall that
      this documentation already sorely lacks any substance.
      Usually, just kernel releases are noted, not contents.
      When compared to kernel source, that proc(5) contained
      many non-existent fields and also omitted many others.
      ________________________________________ <MEMINFO> api
      Sadly, with this api many of the changes were simply a
      correction of some earlier 'human error' where several
      fields where hashed then tracked but never represented
      with an item enumerator in this meminfo.h header file.
      _______________________________________ <SLABINFO> api
      The 'SLABS' (summary) & 'SLABNODE' items were reversed
      since the former are derived from the separate caches.
      More significantly, those 'SLABNODE' guys were renamed
      to 'SLAB' since they concern individual caches and the
      concept of 'nodes' is really an implementation detail.
      Also, several enumerators were changed to more closely
      agree with official slabinfo(5) documentation referred
      to in what we're treating as a base document: proc(5).
      Lastly, while those 'SLABS' items are solely a product
      of our library and not represented in slabinfo(5), the
      names attempt to parallel those found as 'SLAB' items.
      ______________________________________ <DISKSTATS> api
      One enumeration identifier was changed so as to better
      reflect its relationship to that actual documentation:
      'Documentation/iostats.txt', as referenced in proc(5).
      . 12/2018, item origins added (and commit msg history)
      commit 96d59cbf
      . 01/2019, <stat> origins tweaked
      commit 201e816bSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: repair any broken stuff found during refactor · 47af06b5
      jim warner authored
      Rather than offer three separate patches, they've been
      consolidated in this single commit. All are related in
      that they surfaced while preparing a subsequent patch.
      library: correct a broken '#if define', <SLABINFO> api
      It was introduced (embarrassingly) in the patch below.
      commit 97d078a9
      library: correct a broken 'GET' macro, <DISKSTATS> api
      In the patch referenced below, which purported to make
      all the 'GET' macros robust, the 'DISKSTATS_GET' macro
      was broken. A necessary parameter wasn't passed to the
      subsequently invoked function: procps_diskstats_get().
      commit bef8c7fb
      library: correct a broken 'sort' func, <DISKSTATS> api
      In the commit shown below, an attempt to normalize the
      errno handling, the sort function inadvertently lost 1
      crucial line of code which produces a consistent SEGV.
      commit 06be33b4Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: tweak that lxc container support a final time · 32f93b56
      jim warner authored
      Since the patch referenced below traded a compile-time
      'sizeof' directive for a run-time 'strlen' call, there
      is no need to declare lxc patterns as explicit arrays.
      We'll also use the actual lxc patterns by omitting the
      beginning slashes ('/') for both of those definitions.
      And, looking to the future when most/all lxc users are
      using the most recent lxc release, we will make things
      slightly more efficient by reversing those two pattern
      literals so the most recent pattern was checked first.
      Of course, such a change only benefits tasks which are
      running in a container. For the majority of processes,
      both literals will be compared in that 'if' statement,
      assuming the 'LXC' field is currently being displayed.
      [ plus, a leftover parenthesis pair has been removed ]
      commit 288d759bSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: eliminate an unnecessary #include, <STAT> api · a4da552d
      jim warner authored
      That patch shown below should have also included this.
      commit 68d7f7a6Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
  3. 20 Mar, 2019 1 commit
  4. 04 Mar, 2019 4 commits
    • Patrick Steinhardt's avatar
      sysctl: do not report set key in case `close_stream` fails · 866a27cd
      Patrick Steinhardt authored
      As we're using buffered I/O when writing kernel parameters, write errors
      may get delayed until we close the `FILE` stream. As we are currently
      outputting the key that is to be set disregarding the return value of
      `close_stream`, we may end up in a situation where we report error and
          $ sysctl kernel.printk_ratelimit=100000000000000
          sysctl: setting key "kernel.printk_ratelimit": error code 22
          kernel.printk_ratelimit = 100000000000000
      Fix the issue by only outputting the updated value in case
      `close_stream` does not report an error.
      Signed-off-by: 's avatarPatrick Steinhardt <ps@pks.im>
    • Patrick Steinhardt's avatar
      procio: fix potential out-of-bounds access when write fails · 09a36875
      Patrick Steinhardt authored
      When writing to procfs via `proc_write` fails, we try to chunk the
      buffer into smaller pieces to work around that issue. When searching for
      the next location to split the buffer, though, we can underflow the
      buffer in case the current offset is smaller than `LINELEN`. Fix the
      issue by passing `cookie->offset` instead of `LINELEN` into `memrchr` in
      case `cookie->offset` is smaller than `LINELEN`.
      This bug can be triggered on musl-based systems, e.g. by executing
          $ sysctl kernel.printk_ratelimit=1000000000000000
      As the value is out-of-range, `write` will return an error and set
      `errno` to `EINVAL`. As we're only trying to write a smallish buffer
      with a length smaller than `LINELEN` and as the buffer does not contain
      any newlines, the call
          token = (char*)memrchr(cookie->buf+offset, '\n', LINELEN);
      will underflow the buffer and crash the program.
      Signed-off-by: 's avatarPatrick Steinhardt <ps@pks.im>
    • Patrick Steinhardt's avatar
      procio: use the user-supplied delimiter to split large input · 70ed1a72
      Patrick Steinhardt authored
      The `fprocopen` function allows users to specify a delimiter chacter
      that is used to split very large input lines into smaller chunks. While
      the code checks that the caller did actually supply the delimiter, it is
      in fact never used to split the string. Instead, the hardcoded default
      character ',' is always used to split the string.
      Fix the issue by using `cookie->delim` instead.
    • Patrick Steinhardt's avatar
  5. 22 Jan, 2019 4 commits
    • jim warner's avatar
    • jim warner's avatar
      library: improve header file item comments, <STAT> api · 201e816b
      jim warner authored
      This patch just polishes the 'origin' comments for the
      <STAT> header file. In particular those derived/unique
      items (the 'SUM' guys) will now be properly explained.
      [ in order to employ the 'derived from above' phrase ]
      [ with their DELTA versions, all SUM items had to be ]
      [ relocated (and some renamed). in turn, that had an ]
      [ impact on many portions of the .c source file too. ]
      . summary calculations introduced
      commit 2c86c498
      . origins added to header files
      commit 96d59cbfSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: remove one needless function call, <STAT> api · 68d7f7a6
      jim warner authored
      This small change is an outgrowth of the research into
      the bug represented by that merge request shown below.
      With the master branch, a real buglet was subsequently
      addressed. In this newlib branch, no bug existed since
      the <stat> API relies solely on just cpus reflected in
      (and parsed from) the kernel's /proc/stat pseudo file.
      [ since that procps_stat_new() priming read about to ]
      [ be performed will value info->cpus.total, there is ]
      [ no need to separately invoke a procps_cpu_count(). ]
      !82Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: adapt readproc for the latest lxc conventions · 288d759b
      jim warner authored
      The merge request shown below prompted (thankfully) an
      examination of our lxc containers logic in readproc.c.
      As it turns out, the lxc folks changed that eyecatcher
      used to identify containers within a task cgroup file.
      So this patch, with little extra cost, will enable the
      libprocps lxc_containers() guy to handle both strings.
      [ additionally, I was shocked to find lxc allows the ]
      [ eyecatcher to be changed at ./configure time. such ]
      [ a provision has always existed. unfortunately, the ]
      [ changed value was only available to root, assuming ]
      [ one wished to tackle that undocumented liblxc api. ]
      . what prompted lxc support reevaluation
      . original lxc support introduced
      commit 0557504fSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
  6. 02 Jan, 2019 6 commits
    • jim warner's avatar
      library: add item origin (as comments) to header files · 96d59cbf
      jim warner authored
      A lack of documentation seems to be the major obstacle
      to releasing this new library. So, in an effort to get
      the ball rolling again, this patch adds the origins of
      each item as a comment to six of the new header files.
      However, before reviewing how such changes may benefit
      that documentation objective, it seemed appropriate to
      first reflect on newlib's background & current status.
      ___________________________________________ BACKGROUND
      Discussions about and work on a new library began back
      in July 2012 but quickly died. After a lull of 2 years
      those discussions were resumed in August 2014 but soon
      died also (and no code survived the gitorious demise).
      With those early discussions, the recommended approach
      was to encapsulate all of the libprocps data offerings
      in individual functions. When it came to extensibility
      it was suggested we should rely on symbols versioning.
      Unfortunately that approach would have made for a huge
      Application Programming Interface virtually impossible
      to master or even document. And, runtime call overhead
      would have been substantial for ps and especially top.
      So, an alternative design was sought but there were no
      new suggestions/contributions via freelists or gitlab.
      Thus, in spite of a lack of library design experience,
      the procps-ng team (Craig & Jim) set out to develop an
      alternative API, more concise and with lower overhead.
      . 07/01/2012, begin library design discussion
      . 08/12/2014, revival of library design discussion
      _____________________________________ DESIGN EVOLUTION
      Our newlib branch first appeared on June 14, 2015. And
      our current API actually represents the 4th generation
      during the past 3 years of evolution. First, there was
      a basic 'new', 'get' and 'unref' approach, using enums
      to minimize the proliferation of 'get' function calls.
      Then, in anticipation of other programs like ps, where
      multiple fields times multiple processes would greatly
      increase the number of 'get' function calls, a concept
      of 'chains' was introduced. This became generation #2.
      Such 'chains' proved unnecessarily complex so 'stacks'
      replaced them. This was considered the 3rd generation,
      but too many implementation details were still exposed
      requiring those users to 'alloc', 'read', 'fill', etc.
      Finally, a 4th generation emerged representing several
      refinements to standardize and minimize those exported
      functions, thus hiding all implementation details from
      the users. Lastly, handling of 'errno' was normalized.
      . 06/14/2015, revival of new API discussion
      . 06/24/2015, birth of the newlib branch
      . 06/29/2015, 2nd generation introduced 'chains'
      . 07/22/2015, 3rd generation introduced 'stacks'
      . 06/18/2016, 4th generation refinements begin
      . 11/10/2017, 4th generation standardized 'errno'
      _______________________________________ CURRENT DESIGN
      Central to this new design is a simple 'result' struct
      reflecting an item plus its value (thanks to a union).
      As a user option, these item structures can be grouped
      into 'stacks', yielding many results with just 1 call.
      Such a 'stack' can be seen as a variable length record
      whose content/order is determined solely by the users.
      Within that 'result' structure, the union has standard
      C language types so there is never a doubt how a value
      should be used in a printf statement. Given that linux
      requires a least a 32-bit platform the only difference
      in capacity surrounds 'long' integers. And, where such
      types might be used, the 32-bit maximums are adequate.
      The items themselves are simply enumerators defined in
      the respective header files. A user can name any items
      of interest then the library magically provides result
      structure(s). The approach was proven to be extensible
      without breaking the ABI (in commit referenced below).
      The 6 major APIs each provide for the following calls:
      . 'new' ---------> always required as the first call .
      . 'ref' -------------------------> strictly optional .
      . 'unref' --------> optional, if ill-behaved program .
      . 'get' --------------------> retrieve a single item .
      . 'select' ----------------> retrieve multiple items .
      And the 'get' and 'select' functions provide for delta
      results representing the difference between successive
      get/select calls (or a 'new' then  'get/select' call).
      For the <diskstats>, <pids>, <slabinfo> & <stat> APIs,
      where results are unpredictable, a 'reap' function can
      return multiple result structures for multiple stacks.
      The <pids> API differs from others in that those items
      of interest must be provided at 'new' or 'reset' time,
      a function unique to this API. And the <pids> 'select'
      function requires PIDs or UIDs which are to be fetched
      which then operates as a subset of 'reap'. Lastly, the
      'get' function is an iterator for successive PIDs/TIDs
      returning items previously identified via 'new/reset'.
      To provide assistance to users during development, the
      special header 'proc/xtra-procps-debug.h' is available
      to check type usage against library expectations. That
      check is activated by including this header explicitly
      or via build using: ./configure '-DXTRA_PROCPS_DEBUG'.
      . 08/05/2016, type validation introduced
      commit e3270d46
      . 08/11/2016, extensibility while preserving ABI example
      commit 09e1886c
      _________________________ INITIAL DOCUMENTATION EFFORT
      The initial attempt, referenced below, dealt primarily
      with the <pids> interface. Separate man pages for each
      exported function were created. Plus there was another
      document describing the items, among other miscellany.
      Adopting such an approach encounters several problems:
      1. In order to use these man pages, users are required
      to already know how to use the library. Or alternately
      one could randomly search each of them while trying to
      ascertain which function call satisfies their need and
      what exactly was the proper compliment/order required.
      2. While we can explain what all of those <pids> items
      represent, that certainly isn't true for all the APIs.
      See the gaps in kernel documentation for <meminfo> and
      complete lack of documentation with that <vmstat> API.
      3. Our documentation effort should take pains to avoid
      unnecessary implementation details. Here's an example:
      . "The pointer to info will have memory"
      . "allocated and a structure created."
      Alternatively, the following conveys user requirements
      while not offering any internal implementation detail:
      . "You must provide the address of a NULL"
      . "info structure pointer."
      . 01/04/2017, initial documentation offering
      commit 2598e9f2
      I recommend that the newlib documentation consist of 3
      man pages only. The first would cover the 5 major APIs
      and their common functions. The second would deal with
      the <pids> API exclusively, explaining how it differs.
      Any remaining exported libproc functions which are yet
      to be included could be represented in a 3rd document.
      For these new documents the following are are assumed:
      1. Since we will not be able to document all items, we
      shouldn't try to document any items. We should instead
      rely on proc(5) or Documentation/filesystems/proc.txt.
      2. Program development often involves referencing some
      header file(s). So, make that an absolute requirement.
      3. With the addition of item origins, represented with
      this commit, and considering that 'types' were already
      present, the header file might be all some users need.
      4. And who knows, when a user of our libproc complains
      about gaps in their documentation, it might prompt the
      kernel folks to correct those long standing omissions.
      To summarize, I suggest that we replace that libproc.3
      document with a more general one explaining the basics
      of accessing this new library and the common calls for
      most of the major interfaces. We can then create a new
      document (libproc-pids.3?), which explains differences
      in using the <PIDS> application programming interface.
      A final document (libproc-misc.3?) covers what's left.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: insert 'PIDS_ID_TID' for symmetry, <PIDS> api · d9f88246
      jim warner authored
      This change is being made in anticipation of adding the
      source origin of each item to the <pids.h> header file.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: update for fields & latest doc, <MEMINFO> api · 3694a9a4
      jim warner authored
      This patch will bring the <meminfo> API into line with
      that proc(5) document. There were several undocumented
      fields that were not noted and these two were omitted:
      . 'MmapCopy' was conditional on the #define CONFIG_MMU
      . 'Quicklists' depends on the #define CONFIG_QUICKLIST
      And we're about to get the following new field in 4.20
      which will be represented, at least, in that proc.txt:
      . 'KReclaimable' will include SReclaimable plus others
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: harden management of 'Hide_pid' array allocations · ca914276
      jim warner authored
      While setting the size of that Hide_pid array to equal
      total pids high water mark was probably safe, in truth
      there is no real relationship. At some point one could
      exceed that HWM if the 'v' toggle was used extensively
      and at least 1 of those entries remained non-negative.
      This commit simply divorces Hide_tot from the pids HWM
      and bases Hide_pid array size on actual run-time need.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: enable alternate '+' placement with collapsed pid · 22ae5377
      jim warner authored
      Currently, except for tasks that have no parents, when
      a process' children are collapsed the '+' indicator is
      shown in the first position within that COMMAND field.
      This commit simply provides for indenting the '+' char
      so it displays next to that program name/command line.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: plug a minor hole in the vertical scrolling logic · 59f02f19
      jim warner authored
      In that commit referenced below, a few edge cases were
      addressed regarding vertical positioning involving any
      'hidden' tasks. But, 2 additional edge cases remained.
      In a running top, if the user employed 'other filters'
      (o/O) or 'user filters' (u/U) proper vertical position
      was not ensured. And, while this could be easily fixed
      by striking the home/end or up/down arrow keys, it was
      very poor etiquette to shift this burden to the users.
      So, this patch plugs that gap, automating the process.
      commit 9d59ddc4Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
  7. 12 Sep, 2018 4 commits
    • jim warner's avatar
      top: eliminated the use of that 'procps.h' header file · a6dfc238
      jim warner authored
      That prior patch set the stage for eliminating the use
      of that 'procps.h' header, while retaining support for
      a ./configure -DXTRA_PROCPS_DEBUG' during development.
      This commit just eliminates top's use of 'procps.h' in
      favor of a separate include for needed newlib headers.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      library: refactor the XTRA_PROCPS_DEBUG implementation · fab37662
      jim warner authored
      If we ever were to eliminate the procps.h header file,
      as discussed in the thread referenced below, then that
      would impair the current XTRA_PROCPS_DEBUG provisions.
      The only remaining way to verify result types would be
      to explicitly include that <proc/xtra-procps-debug.h>.
      So, this commit will once again enable the ./configure
      provision for defining the -DXTRA_PROCPS_DEBUG option.
      https://www.freelists.org/post/procps/newlib-Qualys-patches,6Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: a tweak to the forest view collapsed code (again) · 19dd4f71
      jim warner authored
      From the outset, top has tried to provide some minimal
      garbage collection in support of forest view collapse.
      For example, with every 'v' keystroke, a check is made
      of the currently targeted pids.  If all were negative,
      which means expanded, that Hide_pid array was emptied.
      Recently, yet another efficiency was added wherein the
      continuing scan for a targeted pid was terminated when
      a match was found. But, one more inefficiency existed.
      When a task which was subject to collapse under forest
      view mode has disappeared (ended), repeatedly scanning
      for such a pid with each iteration makes little sense.
      So this commit will negate such targeted pids and thus
      avoid scanning every current task looking for a match.
      Then, if 'v' is ever stuck at some point in the future
      there will be a chance to empty that Hide_pid[] array.
      [ hopefully this will be a final tweak of the forest ]
      [ view collapse stuff, but cross your fingers anyway ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: the '#define SCROLLVAR_NO' is bent but not broken · 5c8d94ff
      jim warner authored
      This patch simply avoids an 'unused' variable warning.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
  8. 13 Aug, 2018 4 commits
    • jim warner's avatar
      top: speed up the collapsed children forest view logic · 43caa7a1
      jim warner authored
      In forest view mode, once a collapsible parent process
      and all of its children (if any) have been identified,
      there is no longer a need to scan the remaining tasks.
      So this patch will just force a new scan for any other
      'Hide_pid' entries which might remain to be identified
      after a targeted parent has been completely processed.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: miscellaneous accumulated tweaks to code/comments · 52376d16
      jim warner authored
      This patch includes the following miscellaneous stuff:
      . ensure 1 space before any '*' ptr sizeof() reference
      . explain the rather cryptic 'ioa' guy a little better
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • jim warner's avatar
      top: eliminate all of that 'relative enumerator' bloat · 65feb3c5
      jim warner authored
      The top program has always specified the maximum stack
      depth at 'new' time. Then, in those stacks the minimum
      number of result structures were used for representing
      only fields actually being displayed in the 4 windows.
      That, however, complicated all subsequent access since
      each field's enumerator then had to be translated into
      a relative position when interacting with the library.
      This was accomplished by that Fieldstab 'erel' member.
      So this patch eliminates an extra level of indirection
      by fully exploiting the existing maximum sized stacks.
      Now, the enumerators that top uses to represent fields
      also represent their relative positions in each stack.
      [ for fields not actually displayed, the position in ]
      [ a stack is represented by the 'PIDS_extra' struct. ]
      [ thus, there isn't any real library costs for those ]
      [ enumerators/fields which aren't currently visible. ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    • Craig Small's avatar
      docs: Update ps.1 to warn about command name length · 76a2d4c0
      Craig Small authored
      Previous versions of ps used to only match on the first 15 characters
      because that's what the kernel used to provide. Newer kernels have a
      longer length for this field so procps has been updated to suit.
  9. 08 Aug, 2018 2 commits
  10. 01 Aug, 2018 3 commits
  11. 18 Jul, 2018 3 commits