Date: 21 Apr 2004 19:04:10 -0400 From: Albert Cahalan <albert@users.sf.net> To: Cyrille Lefevre <root@gits.dyndns.org> Cc: Albert Cahalan <albert@users.sourceforge.net> Subject: Re: ps enhencements (posix syntax, and more) Message-ID: <1082588650.3450.628.camel@cube> In-Reply-To: <00ba01c427f3$b3477f40$7890a8c0@dyndns.org> References: <019601c426b0$77dc91a0$7890a8c0@dyndns.org> <1082504719.3444.534.camel@cube> <00ba01c427f3$b3477f40$7890a8c0@dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2004-04-21 at 18:54, Cyrille Lefevre wrote:
> "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 ?
No, the point was that adding **any** option to switch
parser modes kind of defeats the whole idea of trying
to be compatible with anything.
You can switch via $PATH and/or some other environment variable.
> > 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,
This is painful for scripts parsing ps output.
> 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 !
You usually have room in STAT or TIME.
> > > (-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.
For uniprocessor, that is a large number you have there.
I'm seeing 6 per CPU plus 4. (10 for 1-way, 16 for 2-way...
and so I guess over 3000 on an Altix with 512 CPUs)
Maybe you don't do per-CPU built-in threads. If you do
though, you can hide most of them behind "H".
BTW, I notice that AIX matches OpenBSD on the "k" issue.
It's kind of defective though, since then it (and old "g")
get in the way of a user thinking "I meant **ALL**, damnit".
> > > -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.
OK, don't admit that Linux has become the standard now.
(You're dying, remember?) Also, you forgot AIX and DYNIX/pts.
Just look at how neatly -g matches up with -U, -u, and -G.
Not that I entirely made this up though: I remember once
finding an OS that only used -g for effective groups.
> 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! \
> ";
I am reminded of sendmail. You're getting close.
> > 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,
As a primary mechanism, this makes sense. What about when
you hit an error? You could add/remove the "-" and re-exec
(once at most!) to get a second chance at doing what the
user wanted.
> > > 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.
This all makes sense for: sz, vsz, osz, rss
BTW, you forgot Tru64 rssize. It's rss with an RSS header.
If you don't implement "size" as being the amount of
stuff that could end up in swap, then there isn't any
format specifier that covers that.
The POSIX spec has a strange distinction between SZ and vsz.
Observe:
SZ The size in blocks of the core image of the process.
vsz The size of the process in (virtual) memory in
1024 byte units as a decimal integer.
For vsz, the term "memory" is used. For SZ, the term "core"
is used instead. If ancient terms were being used, I'd expect
to see "core" in both places. This seems to suggest that the
spec really is referring to what would be produced if the
process could and did produce a core dump.
Damn that spec is vile.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1082588650.3450.628.camel>