[Toybox] ps down, top to go

[enh]

On Mon, May 9, 2016 at 5:28 PM, enh <enh at google.com> wrote:
> On Mon, May 9, 2016 at 4:47 PM, Rob Landley <rob at landley.net> wrote:
>>
>>
>> On 05/06/2016 11:49 PM, enh wrote:
>>> 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.
>>
>> Define "process name"?
>>
>> There are 6 right now: args, cmd, cmdline, comm, command, and name.
>>
>> COMM is stat[2], NAME is argv[0] minus the path, COMMAND is argv[0] with
>> the path.
>>
>> Those are the three variants of "process name", the rest show command
>> line arguments too: CMDLINE is the full unmodified command line. ARGS is
>> the full command line using NAME for argv[0] (I.E. minus the path to the
>> binary you're running, if any). And then CMD is this crazy posix thing
>> that's one of the others depending on your command line options.
>
> compare
>
> ./toybox ps -A -T -o pid,tid,comm,command
>
> with
>
> ps -A -T -o pid,tid,comm,command

(since it's taken this long and you still don't see what i'm saying, i
guess i shouldn't assume you're seeing what i'm seeing...

here's what i see for some random chrome processes with ps:

 86993  86993 chrome          /opt/google/chrome/chrome --type=renderer --lang=e
 86993  86997 Chrome_ChildIOT /opt/google/chrome/chrome --type=renderer --lang=e
 86993  86999 Compositor      /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87000 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87001 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87002 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87003 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87004 handle-watcher- /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87005 HTMLParserThrea /opt/google/chrome/chrome --type=renderer --lang=e
 86993  87008 ScriptStreamerT /opt/google/chrome/chrome --type=renderer --lang=e
 86993 128020 WorkerPool/5655 /opt/google/chrome/chrome --type=renderer --lang=e

and then toybox (ignoring that toybox mangled the large tid for the
last thread):

86993 86993 chrome          /opt/google/chrome/chrome (deleted)
86993 86997 Chrome_ChildIOT [Chrome_ChildIOT]
86993 86999 Compositor      [Compositor]
86993 87000 CompositorTileW [CompositorTileW]
86993 87001 CompositorTileW [CompositorTileW]
86993 87002 CompositorTileW [CompositorTileW]
86993 87003 CompositorTileW [CompositorTileW]
86993 87004 handle-watcher- [handle-watcher-]
86993 87005 HTMLParserThrea [HTMLParserThrea]
86993 87008 ScriptStreamerT [ScriptStreamerT]
86993 12802 WorkerPool/5655 [WorkerPool/5655]

)

>>>> 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.
>>
>> The problem is ps's default output has buckets of free space and top's
>> doesn't, so if -O inserts fields it pushes stuff off the right edge
>> pretty quickly.
>
> (remember i only care about this for batch mode, for inclusion in a
> bug report. so columns are basically unlimited. i think it's
> reasonable to argue that using top -O and expecting to fit in 80
> columns is clearly unreasonable, and you should use -o to choose for
> yourself how to divide up the space.)
>
>> On the other hand what we COULD do is have top -O insert fields into the
>> _ps_ default output fields. So "pid,tty,time,%s,cmd" with the sort
>> starting on field 4 (the first supplied -O field)...
>>
>> Or, -O could replace "pr,ni,virt,res,shr,s" in top... Hmmm, that might
>> thingy...
>>
>>>>>> (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.
>>
>> I just like there to be a short option corresponding to each long option.
>
> many long options just aren't worth a short option. there are 26*2
> available short options, and everyone's better off if they're at least
> somewhat mnemonic but the most important thing is that you can type
> them quickly because you use them all the time. whereas for
> rarely-used long options it's better if you don't waste a precious
> short option, and you're more likely to remember the descriptive
> option. (long options work really well for --something/--no-something
> pairs too.)
>
>>>> (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.
>>
>> I did half a replacement once and I should finish it. Alas, there's a
>> dozen things I could say that about and the past few days I've been
>> wrestling with j-core repository conversion.
>>
>> (And if there's going to be a "sysctl" command, there might as well be
>> an ioctl command...)
>>
>> Sigh, I had this message half-finished for a few days and looking back
>> I'm going "Oh right, I forgot I was in the middle of that" about 3
>> different things. I suspect I should pull up the mailing list threads
>> for the month to re-read on the plane...
>>
>> Rob
>
>
>
> --
> Elliott Hughes - http://who/enh - http://jessies.org/~enh/
> Android native code/tools questions? Mail me/drop by/add me as a reviewer.



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