Date: Thu, 22 Apr 2004 00:54:51 +0200 From: "Cyrille Lefevre" <root@gits.dyndns.org> To: "Albert Cahalan" <albert@users.sourceforge.net>, "Garance A Drosihn" <drosih@rpi.edu> Cc: freebsd-standards@freebsd.org Subject: Re: ps enhencements (posix syntax, and more) Message-ID: <00ba01c427f3$b3477f40$7890a8c0@dyndns.org> References: <019601c426b0$77dc91a0$7890a8c0@dyndns.org> <p0602040dbcab0fdc78a2@[128.113.24.47]> <1082504719.3444.534.camel@cube>
next in thread | previous in thread | raw e-mail | index | archive | help
"Albert Cahalan" <albert@users.sourceforge.net> wrote:
> On Tue, 2004-04-20 at 13:58, Garance A Drosihn wrote:
> > At 10:21 AM +0200 4/20/04, Cyrille Lefevre wrote:
> > >I've finished to cleanup my code and to merge recent changes
> > >made by Garance. I've get rid of my -X feature for now, and
> > >replaced it with -q (posix mode) and -Q (sunos/tru64 compat
> > >mode, aka the return of -g which means -a w/o process group
> > >leaders, and sizes displayed in KGM format).
>
> Having a "-q" for posix mode is kind of pointless, no?
> The same goes for "-Q".
-X has been recently taken.
free letters, are : BDEFIJKQRVWYbukq, well K and k are reserved
for future use... so, why now -qQ ? do you have any better suggestion ?
> > >the next step would have to merge NetBSD/OpenBSD full dynamic
> > >sizing of fields (to get rid of our current static sizing of most
> > >of the fields) as well as to integrate the NetBSD -k keyword.
> >
> > Yeah, I wanted to do more with dynamic sizing, but I have not
> > spent any time on it yet. I have been looking at -k, but I
> > wasn't sure how much it would increase the size of `ps'.
>
> DYNAMIC FIELD SIZES:
>
> There are different choices here. Some can hurt you.
>
> It is good to produce some output before all the
> process data has been read. Think about piped commands
> running on an SMP box. Also, though I know FreeBSD
> never has kernel bugs, suppose some dodgey hardware
> caused process table corruption. You might want to
> at least be able to produce partial output.
>
> I re-align columns as I can. If VSZ overflows while
> there is some room in the TTY column, the spaces get
> grabbed up in order to keep other columns aligned.
> This works well.
the tru64 alternative is not so bad, you know that the size
will not be greater than 7 chars (999.95M). for instance,
the fixed size is, 5, which is too less IMHO, but 6 or 7 will
be to much. however, this suffice in 95% of cases.
under BSD, there is no room in tty !
> THE -k OPTION:
>
> Let's accept the NetBSD direction.
regarding their keyword structure, this will be done w/
dynamic field sizing :)
> SIZE OF PS:
>
> If the size of ps is a problem (for a boot floppy???),
> you can simply create a special ps for that. In the
there is one in picoBSD.
/usr/src/release/picobsd/tinyware/aps/main.c (using /proc)
/usr/src/release/picobsd/tinyware/sps/sps.c (using sysctl)
> Linux world there is a busybox program that, after
> looking at argv[0], can act as ps, gzip, tar, dd, cp...
BSD also have one which is named crunch.
> In case you need to write something, I have a minimal.c
> program that implements ps in 8 kB on i386 or 10 kB on ppc.
> It's been ported away from Linux /proc before, and it can
> work with several non-GNU C libraries. Here is the feature
> set you'd get if you ported it:
both aps and sps gave no options at all :(
> -------- NOW QUOTING FROM THE PR ---------
>
> > (-K) don't show kernel thread (option taken from openbsd -k,
> > *not implemented yet*).
>
> Gee, how many do you have? If they are per-CPU threads
# ps ax | awk '$3 ~ /K/' | wc
43
> all doing the same thing, then only display one of them
> when the "H" option isn't used.
no, there are not threads as the ones selected by freebsd -H,
kernel threads are seen as processes.
> > -g pgidlist select processes by process group id(s).
>
> If the PGID list contains non-numeric entries, then you
> should parse it as a list of effective group names and IDs.
s/should/could/
as a general rule, I tend to follow what other "standard" systems
does. by "standard", I mean, *bsd, susv3, hpux, irix, solaris and tru64.
> > -o fmtlist similar to bsd -o fmtlist.
>
> I have an explicit-width syntax that you might like.
> It does the obvious thing with "ps -o pid,wchan:42,args".
may be for the future. however, ':' is currently used internally,
but easily replacable.
> > -c omits the nice field and replaces the c field with the
> > class field (option taken from solaris).
>
> It should do a bit more than that. Pushing format specifiers
you don't look at the code. as done under solaris, -c works
only w/ -f or -l, but, I agree that it's not documented yet.
also, pri vs opri only has a meaning on pre-svr4 and svr4 oses.
under bsd, there is only one pri which follow the susv3 rule.
> As you can see, had the "c" field been replaced with
> the "class" field, "nlwp" would end up on the wrong side.
lwp/nlwp are not implemented yet. so, there are not displayed.
> For editing oddball formats, this works pretty well:
>
> 1. delete %CPU, CPU, CP, C, and NI
> 2. replace PRI ("opri") with CLS PRI ("class,pri")
this also works pretty well and does not need C code editing :)
* internal format syntax:
* keyword[:flags in reverse polish notation][=header]
* reverse polish notation:
* x by itself, * means any, x! means not x,
* xy| means x | y, xy& means x & y, xy^ means x ^ y.
* [xyz] is a more compact and readable form of xy|z|
* [a-z] isn't supported and is understood as a-|z|
* () may be used for readability but are no-op.
* bsd flags: d12jlsuv, bsd modifiers: nZ
* posix flags: d12fjl, posix modifiers: cMPy
* both modifiers: X if extended.
static char bsd_fmtstr[] = "\
label:Z user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:2! ppid:[jl] \
pgid:j sid:jX& tpgid:jX& tsid:jX& jobc:j sig:s sigmask:s sigignore:s \
sigcatch:s cpu:l pri:l nice:l %cpu:u %mem:u vsz:[lu] rss:[lu] \
mwchan:l(n!)& nwchan:ln& tt:[d2u](vX&)| state:1! tt:[jls]([du]!)& \
start:u time:1! sl:v re:v pagein:v vsz:v([lu]!)& rss:v([lu]!)& lim:v \
tsiz:v %cpu:v(u!)& %mem:v(u!)& command:1! \
";
static char psx_fmtstr[] = "\
label:M f:l(y!)& s:l user:f uid:l(f!)& pid:2! ppid:[fjl] pgid:j \
sid:j tpgid:jX& tsid:jX& c:[fl](c!)& class:[fl]c& psr:P pri:l \
nice:l(c!)& addr:l(y!)& rss:ly& sz:l wchan:l stime:f tty:1! time:1! \
comm:[1f]! args:f \
";
> > -x wide output format (option taken from hpux, similar to bsd -ww)
>
> It's more useful to take this as meaning "show args"
well, "show all args" would be more appropriate.
> and just use -ww for wide output. Adding this option
-ww doesn't exists in any posix syntax.
> will make transition to a mixed POSIX/BSD parser much
> more difficult, because you won't be able to fall back
> to a pure BSD parser when "ps -ax" is seen.
in the actual code, the syntax aren't mixed at all. so, no
transition is needed (except if options aren't preceded
by a dash which means goes in bsd syntax). the syntax
selection is based on the program name, and eventually,
on an environment variable, if compiled in, but it's name
isn't fixed, yet. for instance, it's POSIX, but I dislike it.
maybe something like FLAVOR is more appropriate ?
I won't use any existing environment variable to avoid
conflicts w/ other oses.
> > fname FNAME alias to ucomm [solaris]
>
> Yes, except that it's narrow. Make it 8 characters wide.
yes, I know, but, for instance, it's just an alias and I don't
understand the 8 char limit ? 13 yes, but 8 !
> > opri alias to pri [solaris]
>
> Nope. They go opposite directions.
>
> KEYWORD SOURCE RANGE
> intpri HP-UX 39..79
pri and intpri are identical under hpux 11.x and are
the internal kernel representation of the priority as
I understand the ps and rtsched manual pages. so,
priorities may goes from 0 to 255. but ps shows me
2 processes at -34 which are in class HPUX (aka TS) !
> opri SunOS 39..79
> pri Everybody 20..60 <-- funny direction
wrong, tru64 priorities goes from 63..0
> priority Linux -20..20
> psxpri Tru64 ?????? (direction?)
seems to be 0..63, in opposite order of pri.
> I suspect Tru64 gets "pri" kind of wrong, and uses
> "psxpri" to implement "PRI". Note that the UNIX and
to be a little more precise about priority directions :
pri : bsd, linux and posix say higher value is lower priority -- low value is
high priority
pri/intpri : hpux, sco, solaris and tru64 say high value is high priority -- low
value is lower priority
opri/psxpri : solaris and tru64 say low value is high priority -- high value is
lower priority
in the mean time, I wanted to implement opri as :
#define scaleopri(x) ((int)((PRI_MAX - (x)) / ((PRI_MAX+1) / 40)))
void
opri(KINFO *k, VARENT *ve)
{
VAR *v;
v = ve->var;
(void)printf(wdfmt, v->width, scaleopri(k->ki_p->ki_pri.pri_level));
}
which scale the internal priority from 0 to 40 to match
"The magic garden explained" internal priorities just
for fun :) but finaly make them just aliases to pri.
> POSIX spec only specifies when "PRI" should appear.
> There is no standard keyword for this.
right.
> > osz alias to sz [solaris]
>
> I think not, else why would osz exist? I think one
> of these is in pages, and the other in kB.
I know, but there is no concensus between all ps
implmentations about memory sizes. some uses
pages, some uses kbytes, some, mix them, etc.
under recent BSDs, all sizez are in kbytes, so,
osize too. in other words, implementing all variations
will makes ps too fat for nothing.
> > size alias to sz [just for convenience]
>
> Nope. This is the size of your swappable image.
> That would be dirty pages in RAM plus pages in
> swap, plus anything else (page tables?) that you
> could swap out. Origins may involve Novell or SCO.
well, yes, originally implemented as :
void
size(KINFO *k, VARENT *ve)
{
VAR *v;
v = ve->var;
(void)printsize(wlufmt, v->width,
ps_pgtok((u_long)k->ki_p->ki_dsize) +
ps_pgtok((u_long)k->ki_p->ki_ssize));
}
but, here also, there is no consescus between all flavor
of unices. hpux and irix says it's dsize+ssize+tsize, sunos
says (as I remember me) it's dsize+ssize, tru64 says sz
is rss, while solaris says it's osz (aka vsz in pages).
since the dsiz and ssiz keywords where added, I prefered
to say that sz (alias size) is an alias to vsz since rss is also
displayed w/ -y.
> > wname alias to mwchan [irix]
>
> I interpret related options as:
>
> nwchan hex address
> wname function name
> wchan as wname, or nwchan with -n option
right.
Cyrille Lefevre.
--
home: mailto:cyrille.lefevre@laposte.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00ba01c427f3$b3477f40$7890a8c0>