[Toybox] ps is cheating.

[enh]

On Sat, Oct 17, 2015 at 2:10 PM, Rob Landley <rob at landley.net> wrote:
> On 10/17/2015 01:38 PM, enh wrote:
>> fwiw, android has never cared much about the 80 column limit. we'll
>> show up to 1024 characters of /proc/pid/cmdline:
>>
>> USER      PID   PPID  VSIZE  RSS   WCHAN              PC  NAME
>> enh       18223 4219  902252 142880 futex_wait 7f67f08177ce S
>> /opt/google/chrome/chrome
>
> I'm fetching 2048 chars (half of toybuf) but only displaying that if
> it's the last column and the truncate to screen width option is disabled
> with -w (which isn't implemented yet but I'm probably just having _one_
> -w for unlimited rather than this -ww repeating nonsense from procps).

(yeah, our 1024 limit was just the size of the buffer that happened to
be lying around.)

>> our PC column was truncated on LP64 for a long time before anyone noticed.
>
> Ok, you've got "pc" for what I'm calling "addr". Hmmm. (I can certainly
> add it as an alias. And I _am_ truncating... to 12 chars. Although I've
> already implemented the "explicit width control" logic from the man page
> ala "ps -o pc:16" (and yes, you can use = and : on the same entry
> although : has to go first).

i didn't mean to imply we care about the name (especially because we
don't have -o), just that this is a sometimes useful field.

> While I do want to grab the column auto-adjust logic from vmstat.c
> (which is _not_ the same auto-adjust logic as ls -l, in vmstat it steals
> unused spaces from adjacent columns, in ls it precomputes all the
> columns to measure them), neither really quite matches the ability to
> explicitly specify column sizes.
>
> I'm vaguely planning to grab the vmstat approach (_after_ otherwise
> finishing and promoting this sucker), treating the specified sizes as
> "pad out to", and then letting _only_ the numeric fields (and maybe
> wchan) expand because usernames and cmdline can be pathologically long
> if you don't truncate them.
>
> The rightmost column already expands out to screen size (or to unlimited
> with -w... why don't I implement -w now while I'm thinking about it...).
>
> And come to think of it, the default shouldn't be 80. If you haven't got
> a tty, behave like -w (INT_MAX).
>
>> our default columns are unusual too (the above output is the default).
>> (PC is the kernel's "kstkeip".)
>
> Um, do you mean entry #29 "EIP" from /proc/$PID/stat?

yeah, for some reason we used the name of the kernel macro to pull the
pc from task_struct.

> I see you're also printing it in hex. All the other fields are decimal
> (except the one that's specified as _octal_ by posix), but decimal is
> just too many digits here (and not what anybody's going to be comparing
> /proc/$PID/maps and objdump -d output against if they really need to
> dissect a running process without gdb. And yes, I have done that.

yeah, since that's the only use for this field, only hex makes sense.

>> we also had numeric wchan output for years and no-one complained. in
>> fact, it wasn't until i got a patch to increase the width for the
>> numeric output for LP64 (!) that it annoyed me enough to fix it.
>
> I'm already reading the proc/$PID/wchan data for that field. I was
> considering having addr be the numeric wchan (posix doesn't _say_) but
> it's zero a lot and EIP should never be, so... more useful.

it's actually 0 a lot. the kernel uses 0 to mean "none of your
business". all kernel threads show up as 0 too, even if you're root.

> Rob



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

 1445130270.0