[Toybox] ps down, top to go

[Rob Landley]

On 05/06/2016 08:34 PM, enh wrote:
> On Fri, May 6, 2016 at 6:01 PM, Rob Landley <rob at landley.net> wrote:
>>>  1794  1806 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_1
>>>  com.android.onetimeinitializer
>>>  1794  1807 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_2
>>>  com.android.onetimeinitializer
>>>  1811  1811 u0_a24   20   0   0% S 1518092K  57752K  bg
>>> ndroid.calendar com.android.calendar
>>>  1811  1816 u0_a24   29   9   0% S 1518092K  57752K  bg Jit thread
>>> pool com.android.calendar
>>
>> Wordwrapping in the original?
> 
> yeah, sorry. gmail hates long lines.

Makes it hard to see what you're going for, but I _think_ I understand.
Your fields are padded to fixed starting points and "thread name" is
whitespaced out if this isn't a thread?

>> Binder_1 is stat[2] and com.android.fruitbasket is argv[0]?
> 
> correct. /stat[2] and /cmdline[0].

what worries me is 80 chars horizontal, which is still something like a
standard. (In that theres no OTHER standard when you go past that.)

There's something like 20 chars of space for ARGS now, and stat[2] is 16
of those characters, plus 2 bytes [] plus a space. If we pad that out as
a static indent for non-threads there isn't enough space for anything
after it unless we assume the screen is wider than 80 chars.

On the other hand fields off the right edge only show up if you expand
the screen width now, so I can pad to an even 80 chars and have a new
field show up at char 81. (Kinda ew, but doable. Unless you want to
suggest earlier fields to drop in -H mode?)

>> The half-dozen different name fields are enough of a nightmare I've been
>> pondering pulling them out of the alphabetical list and grouping them in
>> the help output, because I can never remember which one does what and
>> they're currently kinda hard to look up.
> 
> yeah, i've thought the same too. but you can't really win. sometimes
> folks will want alphabetical ("what does X mean?") and other times
> logical ("what are my choices for the 'name' concept?").

Oh _I_ can win in that what I, personally, want is to look up the names
as a group. Whether it's what everybody else wants, I couldn't tell you. :)

(Did you know "top -O" in ubuntu lists all the available field names? I
have not made use of this info yet. It would be very easy to enable
that, iterate through the table and output the string. What's hard is
adding help text to each field that would make it useful, and even if I
moved the help text from kconfig to the typos[] table, that still
doesn't solve the "6 variants of names are buried amongst a bunch of
other stuff, and they're not all mostly nicely collated alphabetically
now I've stuck "bit" in there, and "name" was off on its own anyway...)

I could have two sections:

  Command line arguments -o can show:

    ARGS    xxxx  CMD      xxxx
    CMDLINE xxxx  COMMAND  xxxx
    COMM    xxxx  NAME     xxxx

  Other -o FIELDs:

It's not ideal, but might be better than one we have now. I need to
finish filling out the field list first, to show all the stuff added for
top and so on. (The top help should just say "see ps --help for
available -o fields"...)

>> (Of course when I sat down to clean up the ps help text, the first issue
>> is that I implemented a lot more fields for top and pgrep and such than
>> ps --help currently lists, and when trying to document them all I went
>> down the rathole of trying to figure out what the difference between -o
>> PR and -o PRI actually is, which involved reading kernel source for an
>> hour (the comment on task_prio() in kernel/sched/core.c does not seem to
>> match the MAX_RT_PRIO value from include/linux/sched/prio.h), and then I
>> got interrupted, and I have a half-finished blog entry about it and it's
>> on the todo list. The REALLY sad part is I worked through this and
>> understood it when I implemented it, but didn't write it _down_. You'd
>> think I'd know better by now...)
> 
> these kinds of things are, i think, the best argument for a logical
> grouping. makes it easier to contrast them with one another. but the
> ps help is already pretty long.

Tell me about it. That gets us back to "top -O", except "ps -O" already
means something else and I'd want it consistent so pick another letter...

Having the help be long isn't bad if all the help text justifies itself.
It's better to be long than to be incomplete. It should be as concise as
it _can_ be and still do its job.

Really toybox --help is toybox's man pages. There's a "help" command
that outputs the same data (just like bash has for its builtins, which
do NOT have man pages), and I've thought about adding a "man" command,
but it would need to understand troff and display conventional man pages
(or html formatted output thereof or some such) so the expected "man"
command could show help for things that aren't toybox. And that's a can
of worms I haven't opened yet.

(Still as long as info pages go the way of gopher, I think we come out
ahead.)

>> chromium-browser has 46 threads (and that's with most tabs killed: the
>> trick is to set /etc/resolv.conf to 127.0.0.1 after a crash forces you
>> to reopen all your tabs). But thunderbird has 45, apache2 has 27,
>> something called osspd has 12... I think I'm good. :) ("ps -ATfk tcnt"
>> works great by the way. Possibly I should try to rephrase the
>> documentation so "ps -ATfk -tcnt" reversing that is more obvious. Terse
>> vs thorough, the endless struggle...)
>>
>> I'm still in Tokyo for most of this coming week keeping
>> http://j-core.org/news.html updating (a _different_ todo list is
>> flushing madly, always does when I come here), and I'm likely to be
>> quiet on toybox until I get back to Austin (might not even get the
>> necessary top polishing in this week), but after this trip I seriously
>> want to make a big push to get as much into Android-next as I can while
>> the merge window equivalent is open.
> 
> yeah, it's finally starting to look like the end is in sight for
> toolbox. i'll start another thread with a question about
> getevent/sendevent...

(And I gotta finish ioctl...)

(The end in sight for _busybox_ in my own use cases is next up on my
todo list. Really not looking forward to implementing awk, but it's
gotta be done...)

>> (I've more or less told my boss I'm
>> likely to disappear for a few weeks after this trip. Fix the help text
>> collator, restart mk/genext2, do mk/genvfatfs with some mtools-alikes,
>> implement vi and less, get toysh to at _least_ the level of msh from
>> uclinux (which is only 53 lines long), the cleanup/promote lsof, dd,
>> expr, more, tar, tr, figure out how to deal with stuff like rev.c that
>> does fdopen() on loopfiles and thus seems to WANT a FILE * version...)
>>
>> Hmmm, I _could_ have the argument be a long and then have a flag that
>> makes it give you a FILE * instead of an fd. Or I could switch
>> everything to FILE * by default and then you can fileno() if you want to
>> go the other way, which is slightly less efficient (unnecessary malloc
>> and struct initialization) but avoids most of the horrible resource
>> tracking issues... Yeah, that's probably simpler from an implementation
>> standpoint, and simple beats efficient on a first pass.
>>
>> But that's ANOTHER can of worms to open. I should _probably_ cut a
>> synchronization release with just what I've got done already on the
>> flight back, just to clear the decks for the next round.
> 
> as a friend of mine always says, "version numbers are free" :-)

Releases aren't. I regression test them on all targets as part of a
Linux From Scratch build, review every commit since last release to
assemble the release notes, and what I really need to start doing is not
consider commands promoted until I have the TEST suite entry also filled
out and passing. (Which... "make test_ls" has 2 failing tests. The
reason is just that -a and -A sort output in a different order than it
expects because internationalization whatsis, but that doesn't make
fixing it (I.E. figuring out the right behavior and adjusting the code
and help text to communicate what that IS, and then making sure the host
and toybox versions both pass the tests even if that means setting
LC_ALL=something_funny for the host version to get #*%(&%# consistent
behavior out of it...)

I need to make sure all targets are building so the static binaries are
there to upload into toybox/downloads/binaries and update the "latest"
link. I need to regenerate and upload help.txt for the website, triage
the roadmap for changes, regenerate status.html and make sure it's up to
date, make sure code.html covers any infrastructure changes I've made
since last time... I've got a release.txt file listing stuff, like
remembering to tag the repo AND change the version number in main.c...

Releases are work. Important work, but work nonetheless. (Janitorial
work, basically.)

And I should do one...

Rob