[Toybox] ps

Rob Landley rob at landley.net
Fri Dec 11 23:19:47 PST 2015


On Fri, Dec 11, 2015 at 5:55 PM, enh <enh at google.com> wrote:
> ps seems pretty broken by the recent changes:

Yeah, sorry. I've got more large pending changes half-finished. Trying
to beat the magic constants back with:

struct typography {
  char *name;
  signed char width, slot;
} static const typos[] = TAGGED_ARRAY(PS,
  {"F", 1, 6}, {"S", -1, 64}, {"UID", 5, 31}, {"PID", 5, 0},
  {"PPID", 5, 1}, {"C", 2, 0}, {"PRI", 3, 15}, {"NI", 3, 16},
  {"ADDR", 4+sizeof(long), 27}, {"SZ", 5, 20}, {"WCHAN", -6, -3},
{"STIME", 5, 19},
  {"TTY", -8, -2}, {"TIME", 8, 11}, {"CMD", -27, -1}, {"COMMAND", -27, -5},
  {"ELAPSED", 11, 19}, {"GROUP", -8, 33}, {"%CPU", 4, 64}, {"PGID", 5, 2},
  {"RGROUP", -8, 34}, {"RUSER", -8, 32}, {"USER", -8, 31}, {"VSZ", 6, 20},
  {"RSS", 5, 21}, {"MAJFL", 6, 9}, {"GID", 8, 33}, {"STAT", -5, 64},
  {"RUID", 4, 32}, {"RGID", 4, 34}, {"MINFL", 6, 7}, {"LABEL", -30, -4},
  {"CMDLINE", -27, }, {"%VSZ", 5, 23}, {"PR", 2, 15}, {"VIRT", 4, 47},
  {"RES", 4, 48}, {"SHR", 4, 49}, {"TIME+", 9, 11}
);

Where TAGGED_ARRAY() gets preprocessed to produce PS_PPID and PS_RES
and so on, constants indicating the index position. (Of course
PS_TIME+ isn't a valid constant name so there's still design todo
items here; TIME+ is the name "top" wants for its default time field
with the .XX hundredths of a second...)

> $ ./toybox_unstripped ps -o cmd,cmdline,comm -A
> ...
> [/3:0 er/3:0]               [/3:0 er/3:0]               /3:0 er/3:0
> [/37:0 r/37:0]              [/37:0 r/37:0]              /37:0 r/37:0
> [/41:0 r/41:0]              [/41:0 r/41:0]              /41:0 r/41:0
> [/25:2 r/25:2]              [/25:2 r/25:2]              /25:2 r/25:2
> [/6:0 er/6:0]               [/6:0 er/6:0]               /6:0 er/6:0
> ...

That's also half-finished. The problem is that if you look at "ps -o
comm" in ubuntu sed you get command name from /proc/$$/stat field 2,
while ps -o cmd and ps -o command are _both_ full command line from
/proc/self/cmdline. I know ps -o cmdline came from android.

Meanwhile http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html
says that cmd is "the command name. the full command name is written
with -f", and later it says that comm is _explicitly_ the argv[0]
value, which isn't what ubuntu's ps is doing!

So I need to group the various ways of emitting command line/name,
reread the spec and test what ubuntu and android are doing, then work
out the correct behavior. (Right now COMM is just an alias, without
its own entry in the -o table, but it's got different behavior than
anything else in ubuntu's ps. Sigh...)

> these are kworker threads, as an obviously broken example. the
> equivlent ps output (minus the android/toybox cmdline extension) looks
> like this:
>
> [kworker/3:0]               kworker/3:0
> [kworker/37:0]              kworker/37:0
> [kworker/41:0]              kworker/41:0
> [kworker/25:2]              kworker/25:2
> [kworker/6:0]               kworker/6:0

Hmmm, I was pretty sure I'd checked in a fix for that? (Rummage
rummage...) Darn it, I broke it again during the --sort stuff.

I'm sorry, I'll fix it. I'm just in the middle of another large ps
shuffle. (The problem is that top needs to be able to sort on
arbitrary fields and sorting time+ doesn't work sanely because neither
a string nor a numeric sort will handle:

    14.61
 14:48.51
    15.00

So I need to indicate which fields need their raw slot[] value sorted
and which need string conversion first (-o USER for example), which
means I need the slot[] value of each field available to the sort
infrastructure, which means I need to suck the magic constants out of
the display function (the one currently doing the string conversion)
and instead put it in a structure that lets me do name/value
association which means I should be able to reorder them so I can have
functional groups rather than "the order in which I added stuff"...
(Yeah the new structure is like 16 bytes/entry where the old one was
9, I don't care the code is _cleaner_.)

Sorry this one's being stroppy. It's still not as bad as sed. :)

(And when the infrastructure's beaten into a reasonable shape, sucking
top, pkill, and pgrep into it should be reasonably straightforward.)

Rob

 1449904787.0


More information about the Toybox mailing list