On Sun, Feb 23, 2020 at 12:40 AM Rob Landley <[email protected]> wrote: > > On 2/23/20 12:30 AM, enh wrote: > > On Sat, Feb 22, 2020, 20:01 Rob Landley <[email protected] > > <mailto:[email protected]>> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
