[Toybox] Fun with ps.

[Rob Landley]

On 10/09/2015 05:11 PM, enh wrote:
> On Fri, Oct 9, 2015 at 2:29 PM, Rob Landley <rob at landley.net> wrote:
>> Grrr. Need test suite entries for this, which means the controlled
>> environment with known process IDs to run them in. (Well, known-ish
>> given that I can't control how many kernel threads the kernel launches
>> for random drivers on startup, which changes each kernel version
>> "upgrade"...)
> 
> or you factor your code so you can write unit tests...

I already can. I'm just saying I haven't made the infrastructure I want
to do yet.

> formatting code
> can be tested independently of the code that actually collects live
> data.

So far my test infrastructure is almost entirely "does this command
work", not "can I chop out random arbitrary bits and hook them up to
artificial plumbing that runs synthetic data through them". I'd rather
come up with better test infrastructure than have built-in test plumbing
be a design constraint in the command implementation.

I'm aware I got talked into test_human_readable, but that's largely
because _I_ don't have use cases that tell me what "correct" looks like,
only you did, and you want a different API.

Ideally what I want here is for "top" to be mostly the ps plumbing with
strange -o and some field sorting and trimming to window size.

In terms of testing field padding, I can already do something like:

sleep 1000 &
SLEEP=$(jobs -p)
for i in F S UID PID PPID C PRI NI ADDR SZ \
         WCHAN STIME TTY TIME CMD COMMAND ELAPSED GROUP \
         "%CPU" PGID RGROUP RUSER USER VSZ
do
  testing "" "ps -o pid,$i $SLEEP" ...
  testing "" "ps -o pid,$i,pid $SLEEP" ...
done
kill $SLEEP

And get reproducible output. Although _what_ I need to test each one for
is right justified fields vs left justified fields, whether or not the
first field has a space before it ("-o c" does, "-o tty" doesn't, I
believe it's a left/right justification issue), how it expands at the
end when allowed to pad out to terminal size (or -l or -ll sizes). I
note it's _mostly_ -o cmd,command that expand, although TTY could
theoretically do so, and:

$ ps -o wchan
WCHAN
wait
hrtimer_nanosleep
-
landley at macbuntu:~/toybox/toy2$ ps -o wchan,pid
WCHAN    PID
wait    2400
hrtime  2506
-       2642

Note the expansion of wchan there. As far as I can tell, _any_ left
justified field can expand that way, but right justified fields do not
expand at the right edge. But to _test_ TTY expanding, I'd have to
create a tty device that's got a ridiculously long name and run it
under... does setsid have an option to attach to a new tty? No. Should
it? Sigh, gotta go look _that_ up...

But the design issue I'm wrestling with right now are that the -o fields
are an ordered array, and the order is significant. The array index is
used in strawberry->which (consumed in do_ps()) and in the bitmasks
enabling default fields in ps_main().

Ideally I'd have some sort of generator that would parse some kind of
INDEXED_ARRAY("one", "two", "three") macro and create macros for IDX_one
IDX_two IDX_three, and then I could match that in the tests and use
IDX_one|IDX_two|IDX_three for the bitfield. Other users so far include
vmstat, and maybe mount -o and dd conv= (which gets us into the comma
separated field stuff).

This common infrastructure has not yet collapsed together into something
elegant, and the part that's preventing it is that the array indexes are
magic numbers, not FLAG_X macros like the other thing.

I think there are now enough users to know what the common
infrastructure should look like. Possibly enough to justify the overhead
of said infrastructure. I just haven't got it clear enough that the
overhead of EXPLAINING it to people seems worth it. (It's not worth
doing until it's worth _documenting_, which adds a bit to the bar it has
to clear.)

Anyway, I'll probably finish ps manually with the obnoxious magic
constants sprinkled throughout, and then on the next command cleanup
(second stab at dd?) try to do new infrastructure to make comma
separated fields less of a slog and migrate the existing users.

Rob

(Three day weekend in Canada, which means I can spend a while ignoring
the jcore toolchain nommu stuff and catch up on toybox without guilt!)

 1444510573.0