[Toybox] [PATCH] ps/top: auto-size the PID/PPID fields.

[enh]

On Sun, Feb 23, 2020 at 12:40 AM Rob Landley <rob at landley.net> wrote:
>
> On 2/23/20 12:30 AM, enh wrote:
> > On Sat, Feb 22, 2020, 20:01 Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >
> >     On 2/22/20 5:16 PM, enh via Toybox wrote:
> >     > While most Android devices still have low pid_max values,
> >
> >     as does devuan (32768)
> >
> >     > my laptop and
> >     > desktop are using ever higher values. Auto-size the PID and PPID fields
> >     > based on the system's current configuration rather than hard-coding
> >     > values.
> >
> >     Ew.
> >
> >     Out of curiosity, what is your pid_max current set to?
> >
> > My laptop's at 256Ki.
>
> Can we just bump it up by one for now and wait for it to break again? (That
> gives us almost two more doublings; if the second ~doubling is "999999" we're
> still good...)
>
> The magic value plus probe seems... inelegant.

i actually thought this was *more* elegant because it works for those
people already living in the future with 1024Ki or whatever, but also
doesn't punish folks on small systems by wasting columns in top(1)
output for pids they'll never achieve. (which is a happier outcome
than with the mem/swap displays in top where you and i can't agree
because while showing every last KiB might make sense for very small
systems, it's unreadable for large systems; but if you make it
readable for large systems, you lose the detail for small systems
[706628b94e65cfa9e583d7a54d7cdd8de9f70c63].)

if it's specifically the magic 0 you don't like, pid and ppid are
adjacent and the first two entries in the table, so slot <= ppid would
also work. (having a value in the table that we ignore seemed worse to
me though. 0 is clearly magic, and even sounds like "you work it out
for me".)

but, yes, s/5/6/ would be good enough to get the columns to line up
for me again.

> Rob