[Toybox] ps down, top to go

[enh]

On Fri, May 6, 2016 at 9:11 PM, Rob Landley <rob at landley.net> wrote:
> 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?

well, i can use field:123 to deal with that, plus thread names are
limited to 12 characters or so by the kernel anyway...

my real problem is that i don't currently have a field that gives me
the process name in -T/-H mode.

>>> 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.)

i wasn't suggesting we make this the default top -H behavior, even on
Android. this is just so i can fix the code that generates bug reports
so that the top -b -H -o this,that,the,other output is no worse than
the current output.

> 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

i only found that out while experimenting recently. i'd assumed it
worked like ps' much more useful -O.

> 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...

even though you hate them, this is one of the nice things about long
options. they're easier to remember, and no one cares that you've
already taken --list-fields because they're not likely to want
--list-fields to mean anything else.

> 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...)

that seems too broken for me to believe anyone's actually been using
it. but then one might equally well say that about the kernel's ioctl
interface and it's sadly not dead yet.

> (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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.