From cyrille.lefevre@laposte.net  Mon Apr 19 19:05:53 2004
Return-Path: <cyrille.lefevre@laposte.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7C2DB16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Apr 2004 19:05:53 -0700 (PDT)
Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B063043D49
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Apr 2004 19:05:51 -0700 (PDT)
	(envelope-from cyrille.lefevre@laposte.net)
Received: from mail.gits.dyndns.org (unknown [81.185.56.92])
	by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id D8D1F17B457
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Apr 2004 04:06:11 +0200 (CEST)
Received: from gits.gits.fr.invalid (IDENT:oz97i2xyrql34mif@localhost [127.0.0.1])
	by mail.gits.dyndns.org (8.12.11/8.12.11) with ESMTP id i3K25XJn087598
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Apr 2004 04:05:33 +0200 (CEST)
	(envelope-from cyrille.lefevre@laposte.net)
Received: by gits.gits.fr.invalid (tmda-sendmail, from uid 0);
	Tue, 20 Apr 2004 04:05:32 +0200 (CEST)
Message-Id: <20040420020525.GA66658@gits.dyndns.org>
Date: Tue, 20 Apr 2004 04:05:25 +0200
From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
Reply-To: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: FreeBSD-gnats-submit@freebsd.org
Subject: ps enhancements (posix syntax, and more)
X-Send-Pr-Version: 3.113

>Number:         65803
>Category:       bin
>Synopsis:       [patch] ps(1) enhancements (posix syntax, and more)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gad
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 19 19:10:15 PDT 2004
>Closed-Date:    
>Last-Modified:  Sat May 24 19:26:04 UTC 2008
>Originator:     Cyrille Lefevre
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
ACME
>Environment:
System: FreeBSD gits 5.2-CURRENT FreeBSD 5.2-CURRENT #14: Mon Apr 19 05:29:50 CEST 2004 root@gits:/disk3/freebsd/current/obj/disk3/freebsd/current/src/sys/CUSTOM i386
>Description:

here is a summarized description of changes. unfortunatelly, the manual page
has not been rewritten yet to reflect all these changes, sorry. it's on my
way, but only when I'll know which changes will be accepted or rejected.

enhancements to the bsd syntax are :

-A		same as posix -A.
-a		show all processes with a controlling terminal.
		in sunos compat mode (-Q), don't show session leader processes.
-G grouplist	same as posix -G (as recently implemented).
-g		show all processes with a controlling terminal and session
		leader processes.
(-k keylist)	sort by the specified keyword(s) (option taken from netbsd,
		*not implemented yet*).
(-K)		don't show kernel thread (option taken from openbsd -k,
		*not implemented yet*).
-n		numerical output of the user and wchan fields (option taken
		from sunos).
-p pidlist	accept a list of pids (as recently implemented).
-s		show signal output, same as -O SFMT (option taken from tru64,
		conflicts w/ netbsd -s, aka show threads w/ different fields,
		IMHO, this may be implemented as part of freebsd -H).
-t ttyslist	accept a list of ttys (as recently implemented).
		also accept ttyXX in addition to /dev/ttyXX and XX (as
		required by susv3).
-U userlist	accept a list of effective user names (as recently implemented).
		also accept euids in addition of effective user names.
-X		don't show processes without a controlling terminal (opposite
		of -x) (as recently implemented).
-Z		the label field is always prepended.

output is formated more intelligently when combining options such as -j, -l, -s,
-u and -v.  format strings are combined instead of being concatenated.
so, field are always in the same place.

old way :
$ ps -lu
UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT  TT       TIME COMMAND          USER %CPU %MEM STARTED
$ps -ul
USER   PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED      TIME COMMAND            UID  PPID CPU PRI NI MWCHAN

new way :
$ ps -lu # or ps -ul
USER   UID   PID  PPID CPU PRI  NI %CPU %MEM   VSZ   RSS MWCHAN   TT STAT STARTED      TIME COMMAND

standard posix syntax is :

-A		show all processes, whether or not they have a controlling
		terminal or they are a session leader process.
-a		show all processes with a controlling terminal except session
		leader processes.
-d		show all processes with or without a controlling terminal
		except session leader processes.
-e		show all processes (same as -A).
-f		user oriented output.
-G grouplist	select processes by effective group name(s) or effective group
		id(s) (well, the standard says that is should be only id(s) and
		not name(s), which isn't coherent w/ -U and -u !).
-g pgidlist	select processes by process group id(s).
-l		long format output.
-n namelist	see below.
-o fmtlist	similar to bsd -o fmtlist.
-p pidlist	select processes by process id(s).
-t ttylist	select processes by terminal name(s) which may have the form
		co (for the system console), XX, ttyXX ot /dev/ttyXX.
-U userlist	select processes by real user name(s) or real user id(s).
-u userlist	select processes by effective user name(s) or effective user
		id(s).

enhancements to the posix syntax are :

-C cmdlist	select processes by process name (option taken from hpux).
-c		omits the nice field and replaces the c field with the
		class field (option taken from solaris).
-j		job control oriented output (option taken from almost all sysv
		implementations)
-L		show threads (option taken from solaris).
-M		label field prepended (option taken from irix).
-m		show threads (option taken from tru64).
-n system [-n core]
		specifies an alternative system namelist file
		and optionally, a core file if repeated (this is non standard).
-O		same as -o pid,fmtlist,tty,time,comm
-o help		behaves as bsd -L.
-P		includes the psr field (option taken from solaris).
-s sidlist	select processes by session id (option taken from almost all
		sysv implementations).
-T		show threads (option taken from irix).
-x		wide output format (option taken from hpux, similar to bsd -ww).
-y		omits the f field and replaces the addr field with the rss
		field (option taken from solaris).

both syntax :

-q		enable or disable the posix compatibility.
-Q		enable or disable compatibility with sunos and tru64.
		in bsd mode, leader processes aren't selected by default,
		uses -g to show them.
		in bsd and posix modes, size are displayed in KMGPT format
		(ex.: 1.54M instead of 1580).

The lists used as argument are either an identifier or a list of identifiers
enclosed in " " (double quotes) and separated from one another by a comma or
one or more spaces, or both.  Because of the way the shell treats spaces and
tabs, you need to quote space-separated lists.

Options with a list used as argument may be specified more than once, and one
or more of them may be empty since at least one of the options contains a
specifier, if all the options does not contain a specifier, a warning message
is displayed and ps exits.

ex.:
	ps -p , -p ,$$, is right and refer to the current shell only while
	ps -p , -p '' is wrong.

Format string which contains both an equal sign and a comma are considered
to be comma only separated list. so, both
-o "pid=process id,ppid=parent pid,command=command line" and
-o "pid=child ppid=parent command=command" are well parsed,
unfortunately, mixing "user=user name,pid=pid command" isn't...

<quote "right">
When printing using the command keyword, a process that has exited and
has a parent that has not yet waited for the process (in other words, a
zombie) is listed as ``<defunct>''.
</quote>

<quote "wrong">
and a process which is blocked while trying to exit is listed as ``<exiting>''
</quote>

<cite "netbsd">
If the command vector cannot be located (usually because it has not been
set, as is the case of system processes and/or kernel threads) the com-
mand name is printed within square brackets.

If the command vector cannot be located (usually because it has not been
set, as is the case of system processes and/or kernel threads) the com-
mand name is printed within square brackets.
</cite>

modified keywords :

     state     The state is given by a sequence of characters, for example,
	       ``RWNA''.  The first character indicates the run state of the
	       process:

	       O       Marks a running process (on processor).
	       		(state taken from solaris and irix)

	       Additional characters after these, if any, indicate additional
	       state information:

	       >       The process has specified a soft limit on memory
		       requirements and is currently exceeding that limit;
		       such a process is (necessarily) not swapped.
			(historical state taken from 4.3bsd)
	       a       The process is using scheduler activations.
			(state taken from netbsd)
               K       The process is a kernel thread (mutially exclusive w/ L).
			(state taken from openbsd)

	comm		command (the argv[0] value)
			(description change)
	etime		elapsed time since the process was started, in the form
			[[dd-]hh:]mm:ss (description change taken from netbsd)
if WITH_MAXRSS is defined -- implemented
	lim		memory usage limit (description change taken from
			openbsd)
	logname		login name of user who started the process (alias login)
			(description change taken from netbsd/openbsd)
	paddr		kernel virtual address of the struct proc belonging to
			the process (description change taken from netbsd)

added keywords (bsd) :

	keyword	header	description
	ctime	CTIME	accumulated CPU time of all children that have exited
			[netbsd]
	dsiz	DSIZ	data size (in Kbytes) [openbsd]
	egid	EGID	effective group id [netbsd/openbsd]
	egroup	EGROUP	group name (from egid) [netbsd/openbsd]
	euid	EUID	effective user id [netbsd/openbsd]
	euser	EUSER	user name (from euid) [netbsd/openbsd]
	gid	GID	effective group id [netbsd/openbsd]
	group	GROUP	group name (from gid) [openbsd/hpux/irix/solaris/tru64]
	groups	GROUPS	group access list [netbsd/openbsd]
	groupnames GROUPNAMES group names (from group access list)
			[netbsd/openbsd]
	holdcnt	HOLDCNT	number of holds on the process (if non-zero, process
			can't be swapped) [netbsd/openbsd]
	rssize		alias to rsz [43reno/44bsd/netbsd/openbsd/tru64]
	rsz	RSZ	alias to rss [43reno/44bsd/netbsd/openbsd/tru64]
	ssiz	SSIZ	stack size (in Kbytes) [openbsd]
	svgroup	SVGROUP	group name (from svgid) [netbsd/openbsd]
	svuser	SVUSER	user name (from svuid) [netbsd/openbsd]
if WITH_UMASK is defined
	umask	UMAKS	process umask [43reno/tru64]

required keywords (posix) :

	keyword	header	description
	addr	ADDR	alias to paddr [hpux/solaris/tru64]
	c	C	alias to cpu [solaris/tru64]
	class	CLS	process class scheduling [irix/solaris]
	psr	PSR	processor number to which the process is bound
			[solaris/tru64]
	s	S	alias to state [solaris]
	stime	STIME	started time of the process, in the form hh:mm:ss or
			mmm:dd if the process is older than one day.
			[hpux/irix/solaris/tru64]
	sz	SZ	alias to vsz [hpux/tru64]


if COMPAT_TRU64 is defined
	DFMT	similar to "pid tname state cputime command"
	F5FMT	similar to "uname pid ppid pcpu start tt time command"
	FL5FMT	similar to "f state uid pid ppid pcpu pri nice rss wchan start
			    time command"
	JFMT	similar to "user pid ppid pgid sess jobc state tname cputime
			    command"
	L5FMT	similar to "f state uid pid ppid pcpu pri nice rss wchan tt time
			    ucomm"
	LFMT	similar to "uid pid ppid cp pri nice vsz rss wchan state tname
			    cputime command"
	RUSAGE	similar to "minflt majflt nswap inblock oublock msgsnd msgrcv
			    nsigs nvcsw nivcsw"
	SCHED	similar to "user pcpu pri usrpri nice psxpri psr policy pset"
	SFMT	similar to "uid pid cursig sig sigmask sigignore sigcatch
			    stat tname command"
	THREAD	similar to "user pcpu pri scnt wchan usertime systime"
	UFMT	similar to "uname pid pcpu pmem vsz rss tt state start time
			    command"
	VFMT	similar to "pid tt state time sl pagein vsz rss pcpu pmem
			    command"

	keyword	header	description
	cp	CP	alias to cpu [43reno/tru64]
if WITH_CURSIG is defined
	cursig	CURSIG	current signal [tru64]
	policy	POL	alias to class [tru64]
	pset	PSET	current processor set (not implemented yet)
			(hpux/solaris/tru64)
	psxpri		alias to pri [tru64]
	scnt	SCNT	suspend count (not implmented yet) [tru64]
	sess	SESS	alias to sid [43reno/netbsd/openbsd/tru64]
if WITH_CHILDTIMES is defined
	systime	SYSTIME	accumulated system CPU time [tru64]
	tsess	TSESS	alias to tsid [43reno/netbsd/openbsd/tru64]
	uname		alias to user [43reno/tru64]
if WITH_CHILDTIMES is defined
	usertime USRTIME accumulated user CPU time [tru64]

if WITH_EXTRA_ALIASES is defined

	keyword	header	description
	cls		alias to class [hpux]
	cmd	CMD	alias to command [tru64]
	dev		alias to tdev [43reno/tru64]
	flag		alias to f (43reno/irix/tru64)
	fname	FNAME	alias to ucomm [solaris]
	intpri		alias to pri [hpux]
	ivcsw	IVCSW	alias to nicvsw [43reno/tru64]
	ktracep	KTRACEP	tracing vnode [43reno/netbsd/openbsd]
	longtname	alias to tty [43reno/tru64]
	longtty		alias to tty [43reno/tru64]
	maxrss		alias to lim (43reno)
	opri		alias to pri [solaris]
	osz		alias to sz [solaris]
	p	P	alias to psr [irix]
	p_rss		alias to rss [43reno/tru64]
	procaddr	alias to paddr (43reno)
	resident	alias to re (43reno)
	runame		alias to ruser [43reno/tru64]
	scount		alias to scnt [tru64]
	session		alias to sess [tru64]
	size		alias to sz [just for convenience]
	slp		alias to sl [43reno/tru64]
	slptime		alias to sl [43reno/tru64]
	tname		alias to tt [43reno/tru64]
	traceflag	alias to ktrace (43reno)
	tsession	alias to tsess [43reno/tru64]
if WITH_UMASK is defined
	u_cmask		alias to umask [43reno/tru64]
	u_procp		alias to uprocp [43reno/tru64]
	util		alias to c [irix]
	vcsw	VCSW	alias to nvcsw [43reno/tru64]
	wname		alias to mwchan [irix]

if WITH_NOP_ALIASES is defined

	keyword	header	description
	emul	EMUL	name of system call emulation environment (keyword
			taken from openbsd)
	lid	LID	ID of the LWP [netbsd]
	lstate		symbolic LWP state [netbsd]
	lwp	LWP	ID of the LWP [solaris]
	nlwp	NLWP	number of LWPs in the process [netbsd/solaris]
	p_ru	P_RU	resource usage pointer (valid only for zombie)
			[43reno/44bsd/netbsd/openbsd]
	poip	POIP	pageouts in progress (43reno)
	prmgrp	PRMGRP	[hpux]
	prmid	PRMID	[hpux]
	projid	PROJID	project ID of the process [solaris]
	project	PROJECT	project name of the process [solaris]
	rlink	RLINK	reverse link on run queue [43reno/44bsd/netbsd/openbsd]
	rlwp	RLWP	number of LWPs on a processor or run queue [netbsd]
	status	STATUS	process status [tru64]
	taskid	TASKID	task ID of the process [solaris]
	trs	TRS	text resident size [43reno]

here is a detailled description of source level changes :

*** fmt.c

const char * prototypes added

fmt_argv() say [xxx] instead of " (xxx)" if argv is empty as on netbsd.
mostly for system processes and zombies.

*** extern.h

cflag -> commandonly
now deleted -- replaced by gettime()
vhead -> varlist
fmtsep, posix and extended added
class() added
fmt_argv() w/ const char * prototype
gettime() added
gname()/s_gname() added
groups() added
groupnames() added
lockname() sorted
maxrss() #if defined(WITH_MAXRSS)
nop() added
parsefmt() w/ const char * prototype
rgroupname() -> rgname()
s_rgroupname() -> s_rgname()
s_time() added
stime() added
svgname()/s_svgname() added
svuname()/s_svuname() added
upr() added

if COMPAT_TRU64 is defined
systime()/usertime() added

*** keyword.c

var array modified and reformated so values are almost always aligned
the same way.

new keywords are + prefixed, modified keywords are ! prefixed
!	acflag		3 -> 4 (as xstat)
+	addr=ADDR	-> paddr
!	args		16 -> MAXCOMLEN (see sys/proc.h)
+	c=C		-> cpu (alias w/ different header)
+	class=CLS	-> class()
!	comm=COMMAND	-> ucomm (alias w/ different header)
!	command		16 -> MAXCOMLEN (see sys/proc.h)
+	ctime=CTIME	-> cldtime()/s_time()
+	dsiz		-> kvar(ki_dsize)
+	egid=EGID	-> gid
+	egroup=EGROUP	-> group
+	euid=EUID	-> uid
+	euser=EUSER	-> user
+	gid=GID		-> kvar(ki_groups[0])
+	group=GROUP	-> gname()/s_gname()
+	groupnames=GROUPNAMES	-> groupnames() (no dynamic sizing for instance)
+	groups=GROUPS	-> groups() (no dynamic sizing for instance)
+	holdcnt=HOLDCNT	-> kval(ki_lock)
!	inblk		4 -> 5 (medium counter)
if WITH_MAXRSS is defined
!	lim		nop (still "-") -> maxrss (requires kernel patch)
!	login		MAXLOGNAME-1 -> USERLEN (macro to MAXLOGNAME-1)
!	majflt		4 -> 7 (great counter)
!	minflt		4 -> 7 (great counter)
!	msgrcv		4 -> 7 (great counter)
!	msgsnd		4 -> 7 (great counter)
!	nice		2 -> 3 (-20 to 20)
!	nsigs		4 -> 5 (medium counter)
!	nswap		4 -> 5 (medium counter)
!	oublk		4 -> 5 (medium counter)
!	pagein		6 -> 7 (great counter)
+	psr=PSR		-> kvar(ki_oncpu)
!	rss		4 -> 5 (medium counter, as vsz)
!	rtprio		priorityr() is buggy (xxx:xxx instead of normal, etc)
+	rssize		-> rsz
+	rsz=RSZ		-> rss
+	s=S		-> state (alias w/ different header)
+	ssiz		-> kvar(ki_ssize)
+	stime=STIME	-> stime()
+	svgroup=SVGROUP	-> svgname()/s_svgname()
+	svuser=SVUSER	-> svuname()/s_svuname()
+	sz=SZ		-> vsz
!	tdev		4 -> 6 (xxx,xxx)
!	time		9 -> s_time()
!	tpgid		4 -> PIDLEN
!	tsiz		4 -> 5 (medium counter)
!	tt		3 -> 2 (as the manual says and other systems does)
if WITH_UMASK is defined
+	umask=UMASK	-> kvar(ki_cmask) (requires a kernel patch)
!	upr		kvar(ki_pri.pri_user) -> upr() (scaled to PZERO)
!	uprocp		-> paddr (alias w/ different header)

if COMPAT_TRU64 is defined
+	DFMT, F5FMT, FL5FMT, JFMT, L5FMT, LFMT, RUSAGE, SCHED, SFMT, THREAD,
	UFMT, VFMT	multiple aliases
+	cp=CP		-> cpu (alias w/ different header)
if WITH_CURSIG is defined
+	cursig=CURSIG	-> nop (requires kernel patch)
+	policy=POL	-> psr (alias w/ different header)
+	pset=PSET	-> nop (not implementable right now)
+	psxpri=PRI	-> pri (alias w/ different header)
+	scnt=SCNT	-> nop ()
+	sess=SESS	-> sid (alias w/ different header)
if WITH_CHILDTIMES is defined
+	systime=SYSTIME	-> systime()/s_time() (requires kernel patch)
+	tsess=TSESS	-> tsid (alias w/ different header)
+	uname		-> user (alias)
if WITH_CHILDTIMES is defined
+	usertime=USRTIME -> usertime()/s_time() (requires kernel patch)

parsefmt() converted to sys/queue.h and rewritten to handle
the new "internal format string" format which looks like :
	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.

this avoid duplicating similar format strings and on/off options.
also, blank separator is ignored if the format string contains "=".

findvar() rewritten to handle header specification on aliases.
now, you may say "ps -O acflg=XXX" as well as "ps -O acfalg=XXX"

initially, these functions have been rewritten to avoid duplicated
keywords. this has been fixed, since. also, prototypes are now
const char *.

*** print.c

static function prototypes added.
printheader() converted to sys/queue.h
arguments() converted to sys/queue.h, zombies are marked <defunct>.
	if posix, left is forced to 80.
command() same as arguments(). cflag -> commandonly.
ucomm() zombies are marked <defunct>. also, don't pad if last field.
state() 'O' (onproc) state added depending on ki_oncpu != NOCPU, I'm right ?
	'>', 'K' and 'a' sub-states added
pri() scalepri() macro added
upr() added, same as pri().
rgroupname()/s_rgroupname() -> rgname()/s_rgname() to match netbsd/openbsd
gname()/s_gname() added to handle the effective group-id.
groups() added to handle additional group-ids.
groupnames() added to handle additional group-names.
svgname()/s_svgname() added to handle the saved group-id.
svuname()/s_svuname() added to handle the saved user-id.
gettime() added in place of the now global variable.
started()/lstarted() gcc -Wall do not like %y, %b and %c !
stime() added
vsize() converted to printsize() (see below)
printtime()/s_time() added to handle posix vs. no posix times
cputime() converted to printtime()
cldtime() added
elapsed() converted to printtime()
nop() added
maxrss() handled using kernel mods
priorityr() debuggyfied :) PRI_ITHD added
class() added, based on priorityr().
printsize() added to handle tru64 size output format (see -Q above)
$ ps -u
root 96687  0.0  0.8  1528   980  p1  OL+   7:13PM   0:00.05 ps -u
$ ps -Qu
root 91419  0.0  0.8 1.49M  980K  p1  OL+   7:13PM   0:00.05 ps -XXu
$ ps -qlcy
OL+      0  1328 16850 208     96   980   284 -      ttyp1     00:00:00 ps
$ ps -Qqcly
OL+      0 76337 16850 208     96  980K  284K -      ttyp1     00:00:00 ps
printval() PGTOK converted to printsize()
label() '-' instead of nothing

#if defined(COMPAT_TRU64)
systime() added, printtime() of ki_rusage.ru_stime
usertime() added, printtime() of ki_rusage.ru_utime
summing children systime and usertime requires kernel mods...

many some functions buf[x] -> buf[BUFLEN]

*** ps.h

stddef.h and sys/queue.h added
LTIMELEN/STIMELEN/UIDLEN/USERLEN/KOFF added
VARENT converted to sys/queue.h

*** ps.c

many variables made static and many other variables made local
varlist converted to sys/queue.h
struct list added.
xkeep/xkeep_implied (was xflg) -> noctty
leader added
optfatal -> fatal
function prototypes modified:
	fmt() -> format() kvm_t * parameter added
	saveuser() kvm_t * parameter added
*fmt deleted
getopt loop moved from main() to parseopts()
	sets posix if getenv("POSIX") is != 0 (this is #defined) or
	if the command name contains a 'x'.
	sets extended is the command name begins with an 's'.
	nokudge made differently (maybe the old way, don't remember)
	nselectors / noctty / leader / all / nkept / are handled differently.
	the "new" process selection code has been integrated (or instead of
	and) and moved to findproc() to avoid goto's.
findproc() added, processes w/ a controlling terminal are selected using
	KI_CTTY (this is #defined).
parseopts() added.
getuids -> parselst() to handle list parameters.
addelem_*/*_list deleted (sorry, the new code conflicts with mine).
find_varentry()/scanvars()/dynsizevars()/sizevars() converted to sys/queue.h
fmt() -> format() w/ kvm_t * as parameter
saveuser() w/ kvm_t * as parameter, system processes are marked []
	needcomm/needenv && UREADOK() fallback added
pscomp() shortened...
kludge_oldps_options() posix disabled if no -
usage() updated.

>How-To-Repeat:
	n/a
>Fix:
	[original patches deleted, see later "all-in-one" updates - gad]
 
>Release-Note:
>Audit-Trail:

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: freebsd gnats <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: Re: bin/65803: ps enhancements (posix syntax, and more)
Date: Thu, 22 Apr 2004 02:15:04 +0200

 the original PR describe OpenBSD -k as don't show kernel threads,
 which is wrong, OpenBSD -K is FreeBSD -H except that system processes
 aren't displayed by default while they are under FreeBSD.
 
 added features :
 	-t '?' to select process not attached to a terminal (from older bsd).
 	tsid added in -j format string.
 	at last, implement KERN_PROC_SESSION in /sys/kern/kern_proc.c as
 	well as system processes filtering in KERN_PROC_PROC (not sure about
 	that). both features have not been tested yet, but will be soon.
 
 bugs :
 	ttys are udev_t, not dev_t (this prevented the -t '?' to work).
 	pscomp() getpcpu * 100 or always 0.
 		also, uses typed variables instead of an
 		integer generic one which is more cleaner.
 
 FYI, here are the ps sizes once compiled w/ -O and stripped :
 -current : 38048
 this one : 38760
 
	[original patches deleted, see later "all-in-one" updates - gad]
 
 Cyrille Lefevre
 --
 mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <clefevre-lists@9online.fr>
To: "gnats-submit @FreeBSD.org" <FreeBSD-gnats-submit@freebsd.org>
Cc:  
Subject: bin/65803: ps enhancements (posix syntax, and more)
Date: Sat, 1 May 2004 00:29:27 +0200

 f...ing rbl...
 
 feature changed :
 sz changed from vsz (alias) to dsiz + ssiz (calculated).
 kernel bug fix :
 uses timeradd for childtime.
 sysctl_kern_proc(), KERN_PROC_ALL added -> no filtering,
 default -> EINVAL.
 
	[original patches deleted, see later "all-in-one" updates - gad]
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net
 
Responsible-Changed-From-To: freebsd-bugs->gad 
Responsible-Changed-By: gad 
Responsible-Changed-When: Sat May 22 16:15:00 PDT 2004 
Responsible-Changed-Why:  
I'll be looking into this (as I have time), since I have a bunch of 
other changes that I'm working on for `ps'. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=65803 

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: freebsd gnats <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: bin/65803: ps enhancements (posix syntax, and more)
Date: Tue, 1 Jun 2004 16:18:03 +0200 (CEST)

 feature changes :
 the emul keyword is now implemented, this require kernel changes.
 
 kernel changes :
 ki_emul added to struct kinfo_proc and to fill_kinfo_proc().
 
	[original patches deleted, see later "all-in-one" updates - gad]
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

(linimon) Adding to audit trail (inserting in the middle) from misfiled
PR pending/67669:

 --------------------------
Date: Mon, 7 Jun 2004 02:31:10 +0200
From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "Garance A Drosihn" <drosih@rpi.edu>, <arch@freebsd.org>
Cc: "gnats-submit @FreeBSD.org" <FreeBSD-gnats-submit@freebsd.org>

 Garance A Drosihn <drosih@rpi.edu> wrote:
 >At 12:03 PM +0200 4/27/04, Cyrille Lefevre wrote:
 >>here is a description of the last PR#64803 updates :
 >
 >The latest info I see in PR #65803 does not match some
 >things that you describe in the rest of this message.
 >The following comments are based on what I have looked
 >at in the updates in the PR.  I have not had much sleep,
 >so this message may be a little confusing in parts.
 >
 >>*** the kernel part has been reworked and validated in
 >>     the last patch set.   ...OpenBSD -k ...
 >
 >I haven't looked at what you have for -k, but I did try
 >what you had for KERN_PROC_SESSION and it didn't seem to
 >work.
 
 using the all in one kernel patch I've just submited, all
 would work as expected. it seems I forgot some important
 part to what I've submitted, sorry.
 
 >>      implement KERN_PROC_SESSION in /sys/kern/kern_proc.c
 >>      as well as system processes filtering in KERN_PROC_PROC
 >>      (not sure about that). both features have not been
 >>      tested yet, but will be soon.
 >
 >I am skipping the change to KERN_PROC_PROC for now.  I
 >suspect we will want that for at least some situations,
 >but I haven't decided what situations yet.
 
 as I'm writting the email, all the submitted stuffs have been
 tested and works well.
 
 >>bug fix : -L is missing a break.
 >
 >It does not need one in the present FreeBSD source, but I
 >did not check to see if there is some reason it needs one
 >in your updated source.
 
 this was related to my ps patches. I'll submit a new all in
 one patch related to the the -current ps, so, you could try
 again the new stuffs w/o conflicts and w/o missing pieces,
 is any :(
 
 >>*** this is the last patch set before dynamic sizing...
 >
 >I expect that I am missing this 'the last patch set'
 >which you refer to here.
 
 the emul keyword :)
 
 >>kernel level added features :
 >>KERN_PROC_SESSION, KERN_PROC_GID and KERN_PROC_RGID have
 >>been implemented at kernel level as well as
 >
 >I also wanted KERN_PROC_RGID, so I had added the similar
 >clause to the case statement.  Your KERN_PROC_SESSION and
 >this KERN_PROC_RGID which I added did not seem to work, so
 >I looked around a bit and decided I needed to add four
 >SYSCTL_NODE() entries.  With those added, the new features
 >seem to work fine.
 
 see my above comment.
 
 >>KERN_PROC_TTY_NODEV and KERN_PROC_TTY_REVOKED (the last
 >>two are based on what NetBSD does but differently since
 >>we have to lock p_session).
 >
 >I obviously did not add these, or KERN_PROC_GID, since the
 >update I have does not include them.  They sound like
 >reasonable things to add.
 
 there are in the all in one kernel patch.
 
 >>KERN_PROC_PROC now handles KERN_PROC_INC_THREADS and, in
 >>this case, is similar to KERN_PROC_ALL.
 >
 >I have been awake many hours due to work, so I may not be
 >thinking clearly right now.  But the above does not sound
 >right to me.  Wasn't the whole point of KERN_PROC_PROC to
 >*not* include threads?
 >
 >Also, there are other commands which call the same routine,
 >so I don't think we can just blindly rework everything.  We
 >are now working towards a "5.x-stable" release, so I do not
 >want to make incompatible changes in any API's unless there
 >is some pretty major benefit.  If all we are doing is getting
 >rid of an unnecessary variable, I do not believe that will be
 >worth the trouble at this point.
 
 top ignore system processes by default except if you uses -S.
 unfortunatelly, w/ this implementation of KERN_PROC_PROC, -H
 will be needed to see kernel threads.
 
 well, a better way would have to add a new macro like
 KERN_PROC_INC_KTHREADS to get or not system processes
 (aka kernel threads) appart than user threads ?
 
 >>P_SYSTEM processes aren't selected by default (as OpenBSD).
 > 
 >I think this is a repeat of what you said earlier in this
 >message.  I will want to think about that.
 
 no, this isn't a repeat. this is the way system processes
 are ignored at user level before to be implemented using
 KERN_PROC_PROC w/o KERN_PROC_INC_THREADS at kernel level.
 
 >>PS : take care about the struct kinfo alignment. as
 >>    currently implemented, ki_spare has been validated
 >>    under i386 and ia64 (and should work under ...)
 >
 >I have some changes to improve the checking of struct-kinfo
 >size & alignment, but they aren't finished.
 
 the ones from NetBSD/OpenBSD ? :)
 
 >>-G may now uses KERN_PROC_RGID if WITH_RGID is defined.
 >>-s may now uses KERN_PROC_SESSION if WITH_SESSION is
 >>    defined.
 >
 >Note that for the base-system version of `ps', we do not
 >have to clutter things up with a lot of #if's.  Either
 >the matching system supports a feature, or it doesn't.  The
 
 I've added these #if's to help you to distinguish changes
 between them and to have the ability to test the base
 patch w/ or w/o kernel support :P
 
 >few '#if's that I added in my update were just placemarkers,
 >for something that I intend to pick up on with my later
 >updates.
 >
 >>some int variables have been changed to size_t
 >>     (list->count, prtheader, i, lineno, nkept, nselectors).
 >
 >What was the advantage in that?  For some of those, it is
 >pretty much impossible that the value will get over MAX_INT.
 
 it's just to match the system calls expected arguments or
 return values. using the right types avoid many bugs.
 
 >'nselectors' is the number of selectors that the user has
 >typed in as parameters to the `ps' command.  If they type
 >in more than 32767 different selectors, they will run into
 >problems with command-line length long before they overflow
 >some of these counters.
 >
 >>-j now have sid by default.
 >
 >Hmm.  Yeah, I *think* there was a PR about that.  One of
 >those format-groups, at least.
 >
 >>PS : Garance, if you want a fresh patch set, let me know.
 >
 >I probably should, but I fear that before I have the time to
 >read & understand & test & install those updates, you will
 >just have rewritten them all over again.  This is a bit
 
 I didn't understant why you want to reinvent the weel ?
 
 >frustrating, as I have much more modest goals for `ps' than
 
 yes, I'm frustrated to have worked hours and days w/o knowing
 if it's not for nothing...
 
 >you seem to.  I like a lot of what you have done, but I am
 >not likely to pick it all up, and it is bound to irritate
 >you if you rewrite something six or seven times and then I
 >only install pieces of it.  And I still have my own updates
 >which I need to merge in, as well going through all the work
 >you have been doing.
 
 could you submit your pending updates somewhere ?
 
 >>the current size of ps is (optimized and stripped and
 >>w/o extra aliases) :
 >>-current : 30788
 >>this one : 38776
 >
 >I am certainly hoping to keep `ps' smaller than that...  When
 >I started out on my earlier big update, I was able to keep
 >the size down to 28000 for most the time I worked on it.  But
 >in the last few days I worked on it, the size ballooned up
 >by about 15% without me noticing it.  That still annoys me! I
 >would actually like to get the size back down, if I could.
 >I suspect that I will not be able to, but I will not want to
 >add *another* 24% to the size.
 
 whith todays so big disks, I didn't really understand why such
 limitations ? for instance, IMHO, the problem is more the
 kernel size which grow by more than 100% between 4.x and 5.x !
 
 CC -arch, -gnats
 
 Cyrille Lefevre.

 --------------------------

(linimon) resuming original text in PR:

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: freebsd gnats <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 8 Jun 2004 02:08:14 +0200 (CEST)

 all in one kernel patch
 
 begin 644 kern.patch.bz2
 M0EIH.3%!62936;KWXG$`#<U?@'HP?_________Z_____8!6?>!Z/9'>+WV^\
 M^MW=%GSW'?7SV>OOOOH"ZG>HTH2"^S=&:T4J@%")]FH;*=P#[K4#UPR$$%,F
 MT4\4]3R>FFBF)LH:9--&!-`R!H:!H``2@@F"(1IIJFQ3:FF90VIID`TT9``T
 M```9`TR$1*;!3TTFFTF!&(&U`:``-#$`!H`T!)I*(3$3$C3`4],IM3U-I#TA
 MZC:3(\*,@'I!IB`T:"*)$]35-A0-'J&CU#0QJ#0#U#0`T!D&@``!$H0$``C(
 MFF0%3#U,HQ#U`R-,C3-0]0`\FFH=!W0<!#)6,@L(!!-T"@!`@`F-8(0)'JB^
 MS99!C$$%55%%8@VV(((*+$5*A8Q$44MJL56HVV@VB5I7)@5N#(8X%[Y*D\9\
 M/O:[%`V6E5J"Q$!NW,F2F(VJY+2UBD8PKZ/O;O0^7X/Q<1_+\'$X/%K:+1B<
 MMJ=2P-'$MH3]!Y<R'[.K28K9L#Y=M`9^60BX+;Y;'D#0,<^K@X44)>"GPX`,
 M0/8VP-@0TT1T<)C")6@6_5]2_,);*6N:D-594@HL%(OFEN6.VF'(A-@FMI-)
 MFK5,I:(670'#&D1$0\AX/(>7[_88W)X/+LWLJ>SMH\%L+?0X+1G(4O:A"\F>
 M;27!(6Y>EXFXC%AES!8(R1)@*'<NZ))$Q7V7@,`B:FL6P'!K`%"!",@)Q(@6
 MH0.M,AD1=4+QBFJ!EXJT5A9MN5_PZQ':OZ]+7FS*JK:^.'C@LQQN-C<<2<(7
 MZH)8XE#5<&",["VLC\9)*^<<^6=;23M\E"9KL&.J?;FV9GG#@BQU*;<0SQA4
 MEX9MALZC!3*VQMS3K#R]]1.MP?*'QU/&*'`@.=3WZ2QW/F#WA^!(O4""04)&
 M.6N[QZ./1R6ZK6##DPOQ9(5:*>F*[BQFZ6#($OY=5;6H,.-V,/>8W2HQI;UZ
 M$S!E9&#ID"&?+*L4?,CS4$6"[;&5)5E\H--=63)7^09@"1Q$`@[2")\8\`B=
 MB48GX8MX"G#`"$B0A`1@HHK,/T[CY]_FK"CA@M_O?N+_GN^TUA7&@2$:"A=D
 MO]BZ4)OY]+GDM(S4H6]G!P-$EGE"<&H%'52U8$%C%E%CKK[>[WY?U.A+C?R-
 MFN\.*5-,';IG3045@<I&+N5[IVS2XK6'B[V]RP-HN-I#C9F.-!K)%#KR0BY1
 M!0CMGA`)L<H/Z!W5!J!UMDR`YG(0;`0X@>%A92IU9J1`%<#GU*`!A&=:7IH$
 M#EOY\Z"C0;Q,D85(DE'HV=&1.T'CC&6"N+&F!1>:U6*6%58<\,R9(-`L(.16
 MVLK\=.@E3?5<[Y*878J-H`>%WU5FIZ0@44(J[B)9LV:O.M%VP3CNW=;&TVEA
 MBA$RT2)JAG70I+T8>KU_N_`8'Y]V^LFG#*P+S@I(HNWL]_73L>@)>_T6:Z9]
 M&3IKTBB^M0-?KPK+GH0WII66*,!<TWN6:@##XN[E55L&M+5^F\^B\F]&0)C1
 MX0-GTY1(I;)4LHBNR=?>X27;6&#A7<Q.90";3W!H9GPK,2D9]QNH3*"1%%%"
 MBC9P&R@*HDB`:++:I'Q+H_'QR5F9F9FSOT9(&-D-`"$-.OJ4;EUZEO5\Z0O3
 MFTT@H`3.QL@3(<.J2(H2/#[TS(.3!>HX<\JH:%#1Z]7R1"_^@-@&<7U_=>*<
 MU)(20)%"10C$`C($CS!^I'ZZAI!@D8@?N'BE/46P<4>AX\=?=.XOT]M-#;Z4
 M#U3B>G->_X3#BA.UY))=P,UVT+]HYHL?#AXXIKS9F!PB_%R,9]#-L8;U)D)W
 M[X2#`DN@@;.9BTK8$BI9HG30*%4L.=VE9(46>+=O@7G*4WUI/1R2"Z-_O"74
 MF1OY4?'^[%4>W-7HN.9]`$@<D3995N9R&TF2$S3[,)L#MP+L2-V(P%HG220X
 MWYO(/.F+%9DBY5Y[R$W>YVIB(`6X;$)DG<&_7>?P9Z;\^XUJ<TI02)/V![F#
 M(GSL`I%8(V@95##"?C';K69"DYQ58(`A@UQF1%/HJ-%J#Q"`'WE-(V4<]L@<
 MR;:3A5/57@YD3C`.+[,L<]I`=-0.:[&]921+$H!Y,-J7%J*_1KJ=GP1I58BW
 MA!Z#./N4:5E%OV+9(#UZ:>'NJ;`6[NC4#[^_*K2F<80K$BR."U!666S2MKS6
 MB0(%<OS;^OC6GF`_I!@^T'<?`HC2('4.0H&0$20601IZUZ-2IV#^M3!0^:#?
 M</8?VAZP('MH($->?U7>:`GR9D2X7`AF1)&$0][Y4DCMO6.(8K`9$D0J'^*O
 M'4:4_)B#('O5#YSEY*`5GG25D7@'*&$8=D'`SF.P!O)Z0O&*%M"$2NLCPBX@
 MY>K.HV/MA"US9M6X1U`2E03)ADG'Z51!XO:646E4F?X`6VR.VH8)*G&N5%9U
 M4DDDDDDEJ/Z6C):3$,'<"+EYQ`W&,ZV(+E$R%>#F'F3@FE&2N2L5T>FR3TU-
 M$*#K&^R1"V`3-(3RABK)FID/,N]W>BL9*/093E\SF.$K*NE8[=BLZ2,]F>CK
 M`=W0X+/JK=L@6,""(2A$D]*9/ED\<2FU*<">G>XJP>UU8<Q?%8-9I%2.&3"X
 M%662RTP5`%C$BHZD<7CI>_6%:"LLFTI=)*RBJZ:/JFVU8:DR:E7RU5<LY1E(
 M0&Q>0K/E3/%XUNET4?2+O3%8XC"+=SN]_9WNH91O'+HY.L(O*>HH7W[SFY!B
 M;$[@K0-32M3T`,S7V.Z%'?DCB2;D)L)8L0=K*.'L:72)G+FOGO#9=L[%DT$-
 MCK[]*""&VA$"$TDLZS'<V)]Y#G@LTY;RK8)D<TJ>DC2_#;=39O=,'D+VP/Z_
 M&7Z%6`L_D^:,51PMC$?Z88Y5!%)82*0^;QR%('QDU(&O=`YR(A0;3U_`!9!:
 M@N`LV_0`:ZCM/D?K^=A>KF'L^IJG;@.A^Q_'#9].TT8":0M:\&I;MNQ3$PYZ
 MKNZKL(8%;W;@-`%<L"54A%X!K@!`D0S6@1#$:!7]FAO5R9]I"0DSR\,>\*"<
 M^E=VJR:]ZM0R`*/ZS$ZK-B;3D:1-"JW!H5R$S'AJ,V*8@%#?K9)0V"*B*JJJ
 MO3UY>F0V&E`-T.'.2;E$KO1T/%`T332DE('%,A^P-#F&.[CJ4OG4Q4IP^QG[
 MU3'F_M'/R&&2<4)#D-3P)VC3[*`N(IB5K6*+*E94%`UR7NIT3@IR)N4>H:*F
 MTDXDIS`,N//MI4TP,_`#N[YXF_:WNO6KM`^G1QDDW&>@<DUNO2%\L;X:$/J+
 MH0:UBW46CCX^%R.H"6!,(]U'!8I8Q.((&\&*`ZD2AZ#V\KGZTXADI).L=HWR
 M=DVS9SDG@ZBJMMJ,DM%L);426U&%I8!;])ZT*`?S).B=4W<M.SWR=7B`=-G<
 M$4J(7Z>BJ\P$=#WN0>8XZV]*&.TMAJS(2$G1?.RE:F+^I7T'=53GSQ-7<'C]
 MFE3D/:^]=J,=:Z>US))(22=:R!RQ)G28I'L_-NE5YF*F5$3F'-5V'+2X`6@O
 M54PZFW,.YVGFF:D#)3-+S2)<0=>O,D9!5%54>UUHI$_AG.$V$@R'<XP\OG_-
 M5@*A>AAT-*.G>WP!;0`<O,5]+F=)BR6\'507$0JXO<Y)#WRDA]S@86;$7V12
 MVF8UNA#\-ZOO2R%\3`5<P"PU<"+WPTD:D`J5:"U(H+)M)T_+("Q?E&()\EDG
 M08&02C!2B3"S)N3LND@==6C-Z:G0ILEA4"YD,OD3C,-IOV?)I-$SY^_RTLDF
 M(Q4<"92;]>IEVB*'"!0EXO@P*<HE$HR;!#"!K)?6.0T]>XFT6(#&TT^B\ST;
 M@-8B[N!,)FG1H72!=<1R-@!0<&))&C_@[`-OPX7T"S574F)0#_FPOXDWZRNP
 M)'?_>7:2`M=)P([2?H>=3!&-#.5A"*K?4OJ4O%B8,,HGS-&JZ$YYE=U0*^%G
 MPZ!<!_Z`?-SN^@^N%"0A-'`G[0WJATT:D&]NA9B$"C"$[),+%C;\V*G>ZQ"X
 M!G.P[TF@-HA=>,(=@:K2,@%C]`=&A^=WD")E2M_D91_<VXCTO5FFJ!.'!4FQ
 MM>.8X`71[20H4K798*84LENA2:9T[,A[F!B%DP$?K;:&FL=-3WR91(W-]:E6
 M@0&&&;%T`W:(`&\^T'%TY#@9'V\JKT@&@;XH'Z1X4X\`YAN=(4$/*&R!U@S!
 M[W"&X,,TOV.(N@#/%A2Z`;MT26\C'VTJ6PQ]U+BY,<5?IJ!2$-.)46$6I$VL
 MZ8:<06R8*)<N0G()A2$]3O"<L3M3U6+!Z5J&G<"'&R4!SPWND_X\0QWYAR2:
 M62Y0-6>0::(0I3>#PUXZCQU<\;0<K&Y!/U0V^7AGMRU[=!K-@#<C0A=(2@TC
 MT(7@MZXC5<+#K+*@=!GD('@><![PJ;G;/C.I#V?#-`-$'&$"^7T$H#7A9;5+
 M6ME<\O2FW'4E6#3>^:%9Z[%K`VW5=,"T[Z`5]=UX8#%R-9D3K4J0V!2F!@C2
 ME]X;<0-!C-ZISZ4%@/WRI04A\!VT##<J#Z(':VSQ#`Y5J7G+E89<*6THY&F1
 M6TT.GL'`GM2`=CO8GPI02$(1#V"!9=6UKF*<_04T(&]7`'\<02@:P^4=LXTF
 M@'$'AJ#?ZAAGHY;K%-_A/50]ML`#NG-0@XF@Y$'2!;<':E[,%',.M.T&+.]9
 M%A38ITILN2\-H`0N@G%[P@D1$3I06I4K*BQ]"9A4QF(*.4!!A6I%6&R8[^_P
 MV2L#`8,1&,15BB,E>[W6GO)-LW/';I-H%UT*_@O*D/DFCOW(>V=U"E7FGNI1
 M`NEO)4[TO$;38`1#R#(TZF1B'5#$-L#=U\P,[*8KV4F9K6TG<38P&>LJR&PN
 M;P2_,0U2Y29KNP#,)G+@9`30+1D1)%%IPWSH7HI3#$-_";C>1DB@K$DPB0L`
 MX!:OJ(N'[^-0ZY`%U0UB6WV>_5QU)C,V9P@ZA+I#2?7U+FIJ@8&,(%O/R<(<
 MU53B8@5]FNV`.7>.D>WQ'6"%X-[K"B08C$([6F08T4LWC=2@$(T*2J!8K8@!
 MK>G<0FBT#OS]#9J55L!D4.MYH!N"V^T'GC7E[?5?@??]P^H`W`D#2KG4:BGK
 MX;C8^9%)U,12^WB@SV,-7CP\S;C3O;.18N;B:H9*+($`=!T]Q%A^!PRWV\+6
 M&)EB53:=S=O/&>(155$5445@I%0BL5&,(LR@R(JG:!-#<P%-\.1[.QPK!U89
 MLT?'F@S1D/\<R\EHI$A(FT^W>C`Z=+H8W+9;@FKPZQ0G4Y^GP<#55G-)#KDZ
 M^=!*PX*:XK[8U=&ZEE(N)'<&YRK33NR#!LP&7%OAETQ:;I<(277G\([^\NI%
 ML#<4:<-@[(%#>2B>(98&.'!8@E\<!4?H%@U]O,V\AP#$/Q!GX^!#4&W<ON-"
 MN!O5V"%,`B;Z4]QKG6&6['<Z)*7PK0D##U4PB!;NO)RE,X)'&B'HI/8-!3#'
 M&AY+T3&\!TAP4FWC+X0A(1D#W7J4718.$6><:&9&'$*/=$;<1P1IOXW6K6A3
 MI4J7/^L#OCO4LAL]UB(0,PV#KV0@I(+4I"(:P+MQW%PUB2*=$,ZW[`N20M8M
 M&@&97TS2^NAGXB#2<9QFRN'3$,OZF29,BQ8*(-**>*FQ8Q%9LY'D9X<T-ONO
 M6]G:G>D[(M')0F(`C'2I`V2.2*2'9W:6M!#,'>V$2U+$4AY%Q=)4[/<0P@.P
 M`N%#+QT`6*)WF(6AFOAJY@K`=:9&D8$73=C2B(),00-%/$EG9RA0H5/E6UF'
 M5,/T4X8@&O@,Y(/'D:,VTVNUN&X3*"%]'&A%"E+B[=B%1T%E[=KCD`9>T[C9
 MSD`^,\QTH'$]2$HK8X&T:B'4'H8*Z@#[UU\=I2ZOJV)T)B^[_XU&7=DSO-JP
 M*I9=2:21O#Q;#(?</83)A,TB%`"+%Z%,MMAH0?#TX6"HFJ>?A0*5HC6IJNA"
 M,N&]LD*]K`W`)LR)"T%]N>H?YZ",0@@XPR',RIX^@U0O5`G)1Z[3XQ$_W/^E
 6*(E7B!(BSX6>G2?_%W)%.%"0NO?B<0``
 `
 end
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: freebsd gnats <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 8 Jun 2004 01:53:10 +0200 (CEST)

 all in one ps patch relative to -current as of Tue Jun  8 01:53:03 CEST 2004
 
 begin 644 ps.patch.bz2
 M0EIH.3%!62936>8^'W(`;M;?@'\T?______________^8*]>\^@/H!>;"4B5
 M1V]SVQRBH442]\SOAU[WKWON'0[[/IKA>RL6Z[O;=W?33O:?1]]>KO.YN,S?
 M'IO.F.F]UVA([V#KV4`P=[W%"]>XX%+NWKT52E#K7H;;NTJ!(A+LQMB"4`4C
 MG;B\F[>]O0H`]WP!MOLZOOJ>][[;WS3[9UQ:QE&D@`4$$N[P`ONZG-'TKWN/
 M;W$3Z`4)MAAPIZO>#WWQ[[SWMZT^WVWW=M]S5!H4@`@@^V2SXH)Z!R&<O=[W
 M<'>KN>^F?3.SO96E[?0.UM5T>];W;;;V>65=77N)WMZZ[Q5?3[M>[@?>YV0^
 MV7*]VG2ON]=7V^<WW49</8KZ'+VVP+-P<@Z:HZLF"#CWMSH<[/':@NVW<?:K
 M:Y]#ZMV[;%&I]F=[A*[!"E[Y]SQ>SWMWM1?5]]=T-Y[L-S>[+V,8PAJU6]/7
 M.5KV7;2[FNWM,=7U@]$?8#WN9,NUK?9OO=S[[FOCIZ'+>K@'KU>]\`Y!HW;:
 M\R/9]WW:7R]M9FZVKQW8`>7;NNUCWN^\]V?'V[V-;KW/=T[;4).;;-7=R[UI
 M]'N??7NI4)32$``0!,@!-&@"#$T`T3!J---*:/)J;(F02FA`0F0),F00R",T
 MFDU/:*F_2::-4;TI[2CT]2>0C(,0PD:4D))LE-II-J-3]4!Y0!H:`&FC0```
 M-```2:2(B)IHGHF5/]!&FBGJ84S:GH3-),:"9J>DQ-&@TTR#1@B2("`0T`30
 M1A-$80F"GIA3;0C4\U2/$](TT:/5/4$FHD"`31,)I&%/1/2GDVHU/:30I^5!
 MIDVHTR#0#30`=X!F@=6T%I"$5D"Q2U"*0)(@B218P0!1@HD0BC!@D1D8@I%C
 M`(@+$9)\1`L$8$1801)&#8M!Y4%R%D05A+18$%(A2P@DD)(>LQ%".6K;"5%%
 MB,%DJ$60H"*"U@5"10E&LBR+4A1K`K!D8L`9&!1HRB%&08HB)(H"PB"Q18(0
 M$%!60B*"B"($&5BQ2J1HE"L5&I(C(0907ZCQ40%)B:UTS6)?J0WQ'4?8RDG%
 MI*)9"TE&P;)*52V"-!1M48%5E94+4J,9+85`MJDBQC`5C)&,40:6J*"P1`9;
 M2`HL4&(D4;8I10MD%EHC0%J(V6L@Q`4(RL4%EEC9.B1!0M5&VTHA4P0*,@3%
 M9$<M"(A(C%B(+%P9)&T%`)4)F0_Q!89^G>D8AB4,^[1PS<$8(H;JF9!2.9@M
 MMBA928)7`9&*VX;;%HXU4=K)`U@::GO/H^(*Y@<3),,DA8IP3?JAG24G?M79
 MW2[B:JZKNC/)F*86DJYJ7F"U1EW6SU"MICJIQ0>BU@P^E'VP)?JY)4CS*0I!
 M9*PI4L">DQ!2R09+(*"+F1%@RE:5C2TMDLD-0N8DK4J6J&VC=0+)4QM:#%MC
 M&VXQBR:W"-NMH,"V+8U$HZLLRE79,6I=C:#:VI1;2(I$1,RXTHVC*C+CB09&
 M*XR!0M*ECF#B9"YD+BBK!85JHFI0HT@Q$8-2TK4"J0\6@(*0QJ5@VE$1DMAI
 M+D01@(F)<!`5P8.9!R8BP*X-1+8A2P0HPM+5H5==M9M;6-NA09F9V*4MRE*:
 MC82E:-D98:R,M:8R6FHDQK2U6VLP<3'*1CGX+-&DK*1BP*U%A%K"AHI/$'%%
 M6*HD621,L*B(<;10:VE6"74`;D:E1L+2*"K(5$0L52W,QQ28URVVU)!MI;;%
 MNS;;=3.+BQ175N2E06!!("0,P545AK\/_'VAQ;&-+4K96]B&T#2:C;:6P6(@
 MP&5"L$4U9/TFGRWLGNS/Y0?>E!4VPHB"%?<=+>%--'-#FP<QJ%I=EV6P4C+'
 M(VTDU":DU!K83[M"'GY>PQ?V'^H6;&!5$(3]Q]N^VU@";$"*UM9&06GQ!6"L
 M9!%$5%$#\K"LBAH24^D@;PP?&V+4GPZ%\&`;/93(S&#$3@['!4.[`OV[@(_0
 MB7'"`03-B[L?O0D/!)C>[C*N&_';Z4$,_*A!NV)26;4`<7`W`Y]SZ\@\EO),
 MPB/&OPFMD.&%9#?"1,R=+BR.[ZI#B10+92:SH]3D#9)A,0/EW:Z1#+G+96%8
 M2!C"2:33+66U&C*#;HART,\$N2A8L2:MK8F>L;(+RAH5)RQN+RMFX)Q#0WV7
 M6]X</L3D0#0,-N-,S*6UB68H-B60FH;)&]%D=W]NX%M(<8A94CT61`]7`QJ-
 MB6#>],8;A&4+3-2LSIEBH--9FC2E#(1@P1(A<M*7,:F(8B9:K53",TMI8*:L
 M6I,3+M)J$MF:UI2U:U4HLA6`M$EJEK6LB(LS,R2C`41$(5B3RH2Q-":R44WG
 M#-FMYG90.F]N:XL#6AN,A[GG8(S:_WZERJVP7A3,EYS-0UEBA#N+NO68@A2!
 MU?.@K'N@EM:F6";<=ODN$.$FVV\IVH&)!"UUEPS$Q5PK%(+*DQZ75<(+#$MV
 M!O#0C#AE;HP,34M1WQ@;08R:-IO&DL7+3&62ZV6EM,-L-5#&8WMF]!8F]NJ&
 MG%S)F6?WZ+I'BPN(V<O/(;"*)-ZD8DX3;,20Q-L,HTB);H<@5TZ`34(087:R
 MN9A`:D4@DL*4,R3-!L:!4*)+,7`V.35MN8DUE(E13X@^O3]B_`.OI.'G[O_.
 M?W!ZUWNPG^B*%=L%B8<:FM;P-8:)V'/=H;C0T*84:$MI#O064DV;]EV'!FA3
 MM:S/03%Q--:/,S(0H:Z-4'Y&FIT^M^))79=M\9W=T.M:;P<D4<0G3'5V.*E"
 M*))TRP\G7NO!NSL=;IM>:7BW,R5FDJ5#0LC(5-('8G14F:?XES,WERJPQ*@*
 M46=9GDP-87GT<7KIO6*(V^?<I]1_=7T_7)'_'I?YYN6R[$N$&+9J="7_TW>2
 MRF;1#$V(2(J+Q&8H\LB_P.YO_M:4]%3H^$'4/_W_3X^GKM/\O$_W?AU;F2*=
 M-2ROX:B'P_ZS_ZR\O[UVV-V[*?D_:^/]/9ZO;7J_UMN/W\SG4@_]XOS"G6N;
 M3C+V<OJQ]U-*Y:SRYUPMA'KFZ>KM[U97"GJH+=%F4\4\O+(_XYUOQCTWDO^`
 MF6Y^.WWXL*,=#;[.LG<7/?MST!:3;/_,W_*X^YY\]";3>0@W_Z>NC_O#IBC`
 MAZ-$\3..NBSDLV4>'(#\.=`"ZWJ4'5)TG=P[M"1834*^U:I$4MA*Y]_@OX[#
 MM=I_I?)Q_M0CSF'EO;Q/#;9*PH6!WJ7BW/?.%]1=<U>PVX&VR-,F#<S.;K2:
 M`H=D.+L=*@I>B33K58B*H+A/,G3YI(8<@0?&,?K?I8/+`'-6_Z/^P-.W;1)>
 MM8N>,MPNS/<0K$P5H:`),4H_>#LPB+([85_";+%?Z0#?']?"D#^L'OY\IV%4
 M'D%[8^!C/<.*'R$JH,&(+NV,8.C@/?K-%TR"P7E>=-<`$.;MV.D'WV:<U"PX
 M1PU+F=/-K<DV<(9G)R9K4=DRSG<O7BM;#;H#APR3A*@B[L.$AO=[(3_KK[-?
 M71@Y8NR%K&D01$+9V*3M+2BM(3)"2=HYJ50UFLFD/.AM58;!1$I=6G#PR392
 M4[]W&8E1<>CC<A436<O'$FP>+%WABE&X%%N\#,*`D867FE,$M7X4J=+J99PY
 M?-YC0&,#R:WU?F/GV5*$X]/'."GXI\"/'9_#439*;75YHA,;$4P=LTZ7^G]S
 M/M5WZXS/^C"UVY^["\]9W>B>E!?3Y4VT*-QEFWAC!21#VN[`S`T%J)ZGC*2&
 M[0K]J![4-=-IDX9Z4T]^JIVZIPE>FVWX,Y>P(^5:9W;G:@<I>12R]/-C<XF@
 MW:0=,_J<U3E@5,48*<@E>%CT<9H=]U#AWQV]F;V5K&]$,A4,0X\EZAN9$UVO
 MCZ\<R:!P86[E$G`51G!@>VS/+C9V))I#:I"QVT_FUFFZ_KPP/[6L606,2P=J
 M4Y960EN(&@TD!X+6^SN473<J>!6'>9>W_/B^?[IO?!S[_J]'WZ&XH8F0/S/Y
 M/X#;4P($)!R98<-O-F@CU1A)&B:B`10SK4AT>E!%!.AT?QY^N'[(2F7[K3^?
 M7#NFY,I!ZKG%K"B`D?<AJ9IH,D20Z84\O,LUOU8:$WE7)%44!$J%3=7"\W<[
 M4J(9$&LY:'JZIIQG_G2HJ\:,U40@$FD/7`!Q1B)Z]DFBE-W[>C=*D[>S9NU=
 M\.\_>>ZCIJX+T^?OV<.;93\/A7#F^'A[]WYG=/<7Z:H:/R<A]Y,.VCTH]],"
 M/VT>]//XP]:>K^2O#_W[GIF8W?0.1SUC?6\?RO<_ATYSQ8A5ZQ06I+`.G":I
 M-<F)]^)@5Y7">'T)G7Y4!C[?7XO/ZE]G[2*A$%51%BBHJ/V[^]XVI^?BZBA;
 M*5)4JC%B,#Y7DR0<S!2)6%-,IILJJ*N6%B&:S%%D6:[`:4+[@W_6YC+9_CU2
 M*SYKB'3[^0^K/5YXEW)35QD;*&%CJ8A,I"M.)&0X*]?X'E>\ZYE0[=._S8RB
 MA5$*K-*9=']7M;U[M.G-.FQ5@BJ<[N%],JMA2PNJ'RUD<N%Y\1ZB-C3-K[4.
 M<D_S^OD,UN'?#<)(K%&0F?OL"?P^KP[^`^#Q9*+#_D(!Q^I5Y\1<BT;&#[FA
 MP4:'[Z/CU]M3^2EYJ85<=[!296LL%G];C1^W327ZMI:\.C9O'<X71@-UY9[S
 M6@FL+I&U2%:K,P*J)EV#BC!X*,XH-`=F=XP4H#%K&TR8O@<WEQSX74<_[:"M
 M1T`KQOTCH*';G3UU=(L`Q+4AUV?]L.E*&=#RVV"V-6CV54VTUORU!K9SQIS@
 MLBW6\Q,B`P1=/6853,N"JF,W*7"2EM$-!V#],#QL?#GSOQKPKA,,Z8UAGX=*
 M=+9]'=#RO:Y5"E.^D\P@5"HQ@:U=-B[*3'6+=)K6LL7,7#67!5!K&E4.5JN=
 M-SB8I#F2=6!U=26M*[MA5M*Z456,8>U)C,U13LQD"%#EB@+I5M@.OX\AQHJJ
 M!NTV5Q(2A_Q306*;Z+3'AST/5^K>V:/">=91"\44XWSJ\S>]/MY='(VT$P6H
 M@[.4LB`_XP3MMV<&E0GA)S>NNUUK6<4UB^VX[M%]OY,?IU7QZ=N:5#%[+$H<
 ME6Y#IC&+3JMTF9K/2\%"TJNO*O7H_S3H\[EJQ\[W_%\4#1AIF#`;NW=DN9$M
 MNLA*3)M&>]2[+7YZ.@X52FP]%^#KW_?9,V>+C;]AQY<JE1.;!JHMQND:@7:2
 M0XZNL;-[)XZB4UEOI@V0"&ZU7LUAUI[_#Y<GVW-C/=9IQNP\4\W\D>3U<U%I
 MXJH?U>,=$6UJ5SW'.\UL:8PZ?HZ)O(J.&%!5IOA?ROS'3R0FY;)0_BP?;T>C
 MS_?]_WQ7U,%;,#`?Z@HATQ%?A`0D(Q/.`)<1$#T?D`/NT2@?.H=Z-?R&_X)/
 MM=,G=EI15.R54_+1>?``:I:08_U2X?L#7[M<2!=Q_1L-C.=R;Y@31LI-DVBB
 MQXVL.X_<@\_4^">_,,E,3@8\"J_R^ZGFIS3]["4E?;-N[>E0%,3ER9X*B/=;
 MGI85C#T#(I*/W<VJ6?[O+N=??\2$O=Q2Y/7_3VL$<G\Z/7)H-+@.SB2C\_6%
 MDT1$#DHFUT7H41TA@]4AP#\_X=.P$L>VMOON9I(8G[DH4`O]E%H-W80P=YIB
 M70QAV_WUS(X0(05W1)%:B"2*G4,A)\Z0%#!(;0.QF,BD?10`HP/!AQ!RIP%,
 M#T[EG:D/S.F$Y$%`4FS3#5E'E1/T!HA^+`/$X'4^7/G<^;NJE3<_?\<XCY[G
 MOL4^K.W.PKI2H#E$N%%^%T'-G*0@10?="'9%[-K#'1U?(<WW%A^`CZ8\9H'3
 M*AM^OWZ>J?RZZ:;6]JU/QH'1AC,[UT<J@%M?Z!00)S7`)F)O`]/*S<Z`G?V>
 MQLXAN;^2SW\TAH>$L+1!15451'W^BX**JA(*BO%J"Q1$<W?S9=,\+$GNQ5BK
 MFE/HAU0#ZTGH$GX=AQ+-#I6XW49.0P[D(:72""GN35D=*`PA.PZ!CCW'UR:D
 M3`4JA4B"(>/0YS<[[+KA01+U16'K2HH1+W;GV(%'J3%JEKS(JB.K&V(,"8N6
 M[P;<.-5FU_&`8M>AVT@.E6&\"K`88VJ)&^SEF+FXQ@AOQ^3L?VH`JF;/0<3;
 M="PO=$,+I2\0GE`>D@]$7&J/^=SEG=RVT%$##B&TSX:=Z%(LH[T/&9967>#;
 MNSAR3&1!W=APHF$*5\A>-L\Y"V1PZ0[93<=!VY(-F9`8IJV[\=L;/'2\:*!6
 MS(^C[5I^4&&X7LZI_%P[8PV/NMAR<H?=-I^$/XS@Y?=S9,:D&(6VHLF(8R!%
 MB,'*!RD]J;V'CGL<8JR`=9`SB-HR,\,.#OYU7%Z6U(2)42(676:36I?GL#PS
 M1]Y(\8;FS8AZY3H,D[A"B<0D.EJ%BC<#I/Y`T`YP=ZI(3(3"E>P>X<E_*BN?
 MYL_^85]EO#\9'R0V8UX`X>K[W88K$Q?\X<WBC0<U^WX4V>O1M\--?2LD6B$F
 M.;==AM[O]O9S_VQP]?PA=T(,^!!&R_X>1L^6?R>;?LCJVOTKBJLGG\SS9<ED
 MQ+F59:K^"5.BFM-OLIS@9"8^*/>GX\5.8Z/?.F&-WGY^RO/P?;;W96PQO=7K
 MOK?)G$DV3N),"7!#.A,F9-RIJ?%I]<</76H#D]I9?Q@/RH]R#T,?&\_JB1-<
 MBL-,$^M-)O444\Z5BYO>C6(?GW&L,;I9]XS/&*[3$P/$#E^H`,+QE0R]<^4?
 MXT]D61S3SO#0(7(=(;D14>99GJY1D2G\I^!GD?"NI`+XPDS6+%UC;UYBGN^?
 MRGL_ZYZ/T8&^8TQ>"%L*&6.92:YKS/<<GK^K!_T7_IW\WP_"?Q_!0>B=KXK2
 MU*$IRV'(L]9*7K:]ILX5>8F>G48ZH^]&N&RJ=?'YNS:_IWS'4[?7IX5]MA]I
 M@![T1,CI^@LCSI(INUXM&8Z-$.SP$&E1:]=#Q\T:]IA\AW4R=T3'3Y82_5G/
 M:8I9<]@1+3[;<N[U^)NS%-XEU=WA%&77+O9O_C#)F3`-9Q-/JV,^/`R.0^;X
 ME`<0OQA:`0A9+U3.O[,':P<I&R$LJIP.QG%3\IM9#O0=OIY8)H*K529\3C:K
 M5(%]/U.6YHI'\DDUV4#CWI,?5IK&:]&#\'F]HS"J)X&)37L$TT&]+#SR=1[J
 MA'F?_7*K9>G:$\T9)UIK.((L]0?`8&,R<WU#H<00^YHHDQW,D+.)`1^PF%QA
 MSM3R-H^--LW,$+EBQE2QH%_1,L!KQ\[;"C1HB#;(("J6NB2$/F9,3>;BR(%O
 MT1%#+ZMY]?T_X.&TL:*3.#`AAO]2!9N'^IF.;B8?`KF=V23SO!!!VGVEI`\V
 MR127R`+TD,S"0PZ">#B(?,3Y[_KE5`XD__?!C)@^CKQ&^DV.P9-E/J>[08'E
 M[&A&*&=AF/J6L@,&[HXP"<G<)RI')80%"">XNF!HB_E=T^Y:>TX\G.<.YTA)
 MTZ7O[/L-,IO9SA;]\9<J?!['[KHT1<@TSB=W54DZ=),E`0\RIG;X_QM@^=!_
 MX==\;-@U,%DO"WDKF+"?O<B$D7E9<%4R7(.PUY5C^I.(9"`^3\AE1#;WP,E!
 M"QFU0JZ6B3CPW;MOX7@R6^\G%F;)F_5WBC>$?9*-HX31BL>J-(9Z)V9Y(58I
 M199N3,25F_@/C"'1PCPJ_1ZL$(5.5L3PZ)3A=G73E9>LHC*`MS=>(F?$S#23
 M8>XQ'1;["KL;\/7-C6<[#8R0M];-@\,&MCI\N44,9B#?F;<KE-D)#6\>6NX5
 M7=[="YDV7R-K#;H;LVVUM34-CMA9[EAMD6-;<^O.3J/84&!XS4NWL5BFL<K:
 MW8LYLNW8MUVMSG:>*\9KOCEC"K<LQ/>6G6;]$GH**!H3=,;('Z/H:NG?#AH^
 M0T&&EF0+H6=FMFLWO:*K(6+\Z5I5_#U]JM`KH<=.$L=4QFDQM,S*EU#,M*LF
 M.0U6T>ME+LDQLC"=.H!W8IM,342C63J$LVX4:AR>W]@KIBI&XEE"*EYJQ9.S
 M)M9PFUZ*S<HUPQJ;8BLIM*37('(_[YD^>ZGHLIW]<W@3'TZ/_.=CJW^F$WK^
 MR$R(XO%W:2/L@[NIXJ,ZC*>5"E-,2)R)1;%Z8KV'_'U^DO[S[LS1T4P7RSD"
 M&_0P@_;]>/TG22/Q;S0@<K=WJ[(G:WI_:`C4:O2O=J]C*?5(@_\I#`WV*/T0
 M<(,OC<+R'`@GV8OR-7`&$I9]7\\\=AM?OWOI_S/5L;#!ZC:[<S/3^!L2^;O-
 M2F<FY;!P_#Y/;Y%?<U151$K8H(HM-#32N7Y[O#89O-[=3NLLE_S&LSZ5-_9R
 MOO@;2_1`3NPY%R/YIH*7+<P82Q295)K+/1XP,J1'*<3Y=0?E^#SI9/]Y3T0E
 M)WB[P=W?6B'N%@R/WKZ&-VB0P%:;2AG$FB'(4BU"E*\<'-=L"VQV8#)("+W<
 M;L_=.`B`LB[9&\:R^G2<LNR6(Y?I^37<5@0FOA;=F\DF#7WTXZ9'H3,S8(9A
 MD`PP(9C[]&9ZM/`M".A;D6S\[_6]H&UXQ=D_)`A#0TR/\9?IT3?P%;0:<0PC
 M$DD)F3IV!,)A:C3?([I5SLSC')*'!M`FJ3-99/S''BL*F8K5B0;YM4[R(9'3
 MZ[+&"")W/]._?D4']P^AL8]_36XPP([/#0E?V1"4=N!]Y2+,T8!)=NL'WWZZ
 M'B?E_F)8<$W;RK,CT&6^0S10B*5Z;*EVKY?`[TU>_MVEN4H($SI/AW<[`F!0
 MSQZ;H-C*@$:=/.X(BVU]!`9@-G<O?EXB5FNVPM*YB;BT"::;C`&:\(QAEEHF
 M/PY$.)@HUO!,<G?[[_Z27,]E$9;+":C'#P$^@TYL0@_>B.H_%G.8U-*"!^=9
 M4OCJB1OZWJ20?;0?2(5Y,3\H5I=0_.,>M[;%*YG%VLEUS"H#KJ>>8VKUBD.R
 M-<QNFSJ/*T#.D8C=N)T,`YAE;1GZ<YSR=V98(SC3A9]Q!36K?VSF(E)A+1W/
 MST='I^JL+F/K43)^N9X_=SE[IK8<O95IL_)C,J(.W09\M6N$Z8GNP]EE>!L>
 MR.)V_NA?N_8V\H-FR1R.-(C\U![?A2_F&UF3NW@<Z:9FYM_/O>G<M?QVK"RV
 MLP2D/9JB[Q$B%M4&^M]</$OCL9CCC46W\TRC'9AVK8OFZVT+DP>-.Y0?V[,?
 M;RWAMHZ8,#=]7@CG,49+@K!$W)F2`0C)AM)T5DN#)%<E,G*LMOQ(;.1=Q)R*
 M'(\M0SJF2KJCM^;7PBTI[CHRJ.S31<))NP'N=M#K5_MH1B,!89,AZ0]:^$,!
 M&I47G6R)CR["$UQ"Q3\+%RS<EJJ-1R_=PTZL"N%>BZMNKZM!.=TL$UB.,SUV
 M]4!94`N:MV]"$P@2$80HD4?P4K!RVTHR&A)*P,00R9,R24:(4YYW=&YR"NZ)
 MX6VE>J$+/2XWVUJG3G6VNV8;MGXW><:$VD96,?KYP$%#KT](&>C@=-FEC.L\
 M:ELGR,'X_QCZN6D4U".1C*]@'23,D))B*'8,9S'A1$_0X5%NP(-*,)DUB6W9
 MGK\;RA/1"0H7[9]9Z.HWE>G^*C'NJURLH=/#A+1'.?5#H\D:8MA-$GH/"1FL
 MK7V")_?.R]9W*.1!H2"<\V9F#Y%!J>6V`@M+MW5[&E-1'HFD5+B8OQH;..Z;
 MF.&J?_';3HT#5EN5&Z_I6FC;&EJ]=S4.""M^=/)"+X6AEFZNS.S(V$*W'W=*
 M9>P`;5/9=-5[8""N_5;9SHNLRU&=4/M?$:\)RF&D[L9K.C;`T*MM/%RUM.^V
 M?%IB^8R4T]U`<UL)V^;YORQK*\/H0=>W.&MQP<JZ?E<\A@L]'YQ'CWP$]K7\
 M*#<YA^(CIU4PE*$%]+!:9%S1N7O!ZLVX#G8<I$;Y7M:]3O57/><;(]4M`:W#
 MCQ]VB9N4I0CC!4,?(]S7@M&;F!N1Y8#->Y9\*EOX_/23UTA+[?!V]9@<TVML
 MO;_*\+>ZQ:%<)CV]!;;*79@/41'J*XYHO@J9B+FPV#BX"&?"GA$:%;RT!4;Z
 M],MUOEIQQ2$)"21SO=<;,YE:)TB;).8*ZK&C17C%-;!+Q>W`J+\O3.^A-I@#
 M'ASXFG1S?<&GL1%A$\(/Y:K)FR)5;3E,W)S:R--4B@L)?Y//=DSKHP>U7T$5
 MPNU/=@7#7<'DT5)_RHJQ!*#$%:P!>;-3LE&LDF<Z,G:,Z.=/3*7&IY6GL*:Q
 M<KX"1"?+).0B!;#PAOL]_^)7GYUS)Q#%.$%/&4K"]Q]_`U8:K(*#`XQ//H!T
 MR?KPMKRE<6?M_HP<)KU^T*&1@A%D4ON%2J&H3(XF#P,R[8HF8.>57_O35/)M
 M0[.0<N>,1R/QT?C@2GG:BB))&M.6N3-30[K3%S;;V^SK,OKHOU4JCFC#VNV,
 M_'/Y=N!IGYGU[ZN%VK%S5D:[(LU@,F/!L\!1(DF;S"$D+XDI?+&8(0A(X3M3
 M58!M,!3&M@W+.5/J-.VG051:L[]?YX^&?DO:A)%W]W/D$A_]<#'I%W@2$F$@
 M_E5%%6"(*1UKU]P3Y>DWI?H]NC`^NI&9RA.&]R<2,]L#VE14?7D$M)"WJM+>
 M+3@T^ERN/%[MYFZ!**?6$2CIQLD\6KU:GB:;K;,D"M'DYC^/)];URZ:^"A4J
 M5[M;O`_@_TE;,S']3&6?H>NV3'72:%A;V.$+&&*AK$D,V+@Z0A#[)'!:QU/L
 MWU]9J9\KWI0FOJ&-J4".1>Z6:YLT2_@R`VI:BBMP;?7WS_Z$6X:K7/VGYMZA
 MR9TU#*#M'>%>$WV;?_-M)I,"\>Q%7+AL=1(,;ELJQV.-&6,(?(BW7':M#>[_
 M,<]XHQH_+$1#_FI2Z+G.Y<TP<>+M\OJ8>RT:!SX#(IMF@<_/GX$5&C31FTJI
 MH:<NIMVV#-92U'64D*IM9B_5V$-N^D?>N8)9K<=FYX$7+;8.E'[:TQ&!D/+M
 MB03>8]N[A\^R>XH;R'0`A!R8\(5G@LHT:"MH!PY**Y^WVL,DS.&^AACMC,<R
 MY2Z%KV-(WRA7TP)1,*2%2T&$;A7W6:LHO$XIYV'27"N+_SC""?IO.C/N=N^_
 M7JJKMLAZHPQ1U[6'.&:J@:1RK)GAB_:%DV$9S8RTR)KSS-4)>3;X@N%$+**"
 MH5L:U?&,=JF<JSBTKTGF4/&#N%1OU:OMJ?9XGRK7K6&'S)[D,D=E9--O-G@C
 M9'7HR?6J&#2QI=YD7ZZSI-)\T"$OBKTZWUCT07/1>H&RRN>>4]E$R)M>?LKG
 M^70M27\OS_&5IVW/#75`TIH<)2.A2U+6T^FE/G(T[BLW.\^Z5W1)<;N:_`G0
 MBT+^_4H40DRZ5;/M:^PF367`BVAAFY;WX6U*7VI[H/BOK]1VT]-<:\:'/:]:
 MGQL24W-+M(L1R*/2OG_YOI7%T+I_J[9)_"-S&*Q5H_5+'7[6UV4H'<O29(*7
 M#!]QR^7R[T\[>8_+CPZWM4?$>5KKP/'-1:TBJZ'8X9AM9F"=S`55,]7+*-=!
 MI&$WE<E1;J&XTTT\V+:$7\9!QM*3;S^K^5]NTV&M^NZ^'OYYT7()38DM@Y,V
 M['SPFF+$Z$0G(3MLF[$YI+'RGR\[T8,4TQ/0L#B!!LHZIOO9N7YXL8&_QY&1
 MD7E;=T8B_LC>*R$B1%.C3EE*SE)M;>C?O_6,(:(QC'\8:V.]N>]N3<Y<A'2Y
 MQP=APT\.R/(MWRS=EV_`(I33]U_O4_&7(3XYU?GKU4%3=\KV_+!J8UCL_SQZ
 MN9Q\,60FT6<YE\QT%:W3//?]&]<41Z6VCS8%3L9[J(>%WF8*6.S;FNQ=ONP8
 M:G^C"2</.M,R,1`_'RVOO1O&#;U.9,U_1JZ6$S%/;T]?U%?Q\Z-(?0P-W=^&
 M-_#-15455!3UDZ:^J>;GK*3,J*:2?DY*]!S%&GPOG73M#QF\FQ3-CS`Y-_`]
 MVOJ$_8[^A>>^AQR07B2HVI[<T*S%)YE7^ZE:GOZ6Q0TP'T)YG!\O%H,/H'[>
 MPV5J[Y=Q(/2[6_,P:E?A,,O^)V*4]=:UI3F3:9^/ZQZ2[X*^KL/I943IZ$9E
 M)E`FC=YAQIN[9#,09(8/*F9FZJ<N$VVO*@F%\5.,")0>2#9"Z);Z])"J.->\
 MX0+VI^RD9[GQ6U,Z$F:^MBF?GL)<G0)D*7U<W?K:-C(Q+*HV)CXX40,#=OUS
 M$6]==AAF^^+J!?0%A?,QSOSU)^XOH+T&C\8`WKC87-MKIECN.$#:0-@SM<[F
 M2!HMB3ENL0VA50I%`BC6R(&^=#=I&6^1.H/#3WGK[7Y>^_;'EDPU,47</%,/
 M/KURB(>$=[33:UX.Y+ZM6USJ5I0?NA"Q^H=SZ7OO:IW#;>XF\ASJ`WUF>Y&L
 MT+*:&6JWO0\S/5%]^\CI/Y.#^))HB46+F&T-.W`A=Q^;I<E*W@\CSW>UJ]1V
 M^Q8ZXTK%,7GFUR[U---:;TJ%M*3#CV=GHY+4U,RL.ZF""TW"&G6G*-+J8@=Z
 MXP_3MF=-\9F;WVG+Z*Y,W=R[MME[["]T`Y;&MU:V<UR8S?6:[+E9SD1)L3L&
 M6)Y6T:7JXQQI(6<Y'W#U=]UHP7JG87Z9$K!KOB.GTG+.MK[[<DVO*FW2>!S,
 MA!$Z<NFW7X_A\K!R171`C(SHV1!X#CHT*XR_P]T?#O05QJ>G.-#OZ7;MVJEH
 MK%SGA<6BA3G:+3Z$;T)LS5I':G=15*V:^HY9JC+)-26,V!@S0O?R%WFGYM>]
 M[SCA&Z_?3;??CE0U$Q-,_20@0WXP06EU:Q]>""WJJV8OCYES"^#&=,61;3[_
 MA)\GD%C;U\SEV+)\&JE";R>\4+NU<UV5J+GSICCFXIO-GKKMLY]-Y"S!VR;E
 MV2IEA1B1MU9S2*;\KJR$.F72DZF3P=2-Y?9G&5C+)X*NBP<U32ZQ9-!V-V+D
 M)@<S174)>Z;CG'-ZA.G8TS2?/3`T:=+3-%)')I[II:+KK2_AXT=<[XSWE(+2
 M=?=25X>@AWGJOMM,I?B\\2IK/W$4J'H)D=B=?WSN[,SD(\EH:60/"-F=E>H9
 M-V=._X;140!%2*(1!8@K(23(%:-F('C=PRH)HN%UJ@/!M_5;?73>7MJC8]3\
 M&V/U\9/K?U35NV#J1?5OV4[]SIRM%ZS\.?*FG8NYM;)\Y1M$UX^:\='H[E$Q
 MS7@FDIN[F81O>/<2<T]=DE0G,ZPG,^W72KL(9WF7D:J:EI;&/H,_F1"HF;/V
 M*P@U(3X_'--"4$I:8-I\?9ZJ)Z5G5=K]F.?,-2B#Z9)9_@A@B@"P1(#Z[)6"
 M("(B'8P/(F#PPTY;"544%(*#20S.F",E4AIDTH2((,B),;#3S>U'Q'UOM4_+
 M]W_?YZL?GXX<M=/W?LC#]'^+Q3[+Q!_-)\0A8CG1AA,=LT6Q@KM%)"E1>@,R
 M&_@.QX0?Z01_[7Z?Q$QUAR#L?7Q_O/P#^R+^&OR*KX>'V%VZ`0FDC(JQD502
 M282\*`[NKP9<$(18X?S]3<OJB',N;MP_OYKS.>W3F]6[#.U&V_M*^&'"J_$7
 MR.NKOF'=2IW?W4!0C(@'EI(7+U29EJ,B(C!C%@@>D^C:>?#W7M:9WOH]^-$_
 MF]E.VI_;MFUT45P^G??7;]1;A?86T4E+U)<8WT^%LG"#A&O%(M^/T:6J^'I&
 MG;`ENG7\U_6HC_*.SSR:4?P\#A_26U3"B%2WBN6QYK(SJ[!VX_+8QY(NAKV=
 M_%87<=E=F[9QA"/)6*:94%!F3E=)QX%EE#ND]M174<)I1.!"SE'E483EQ<>'
 MT+XT>OQ^F@KO+<VB;!2N#L)B1([";$0Y$Q(9D#24!'G<W$'L2GV6$21E:GC]
 MA0N3A0<RLA@HJ%T6BL<$#E1$EBTQ(EA25"*<:3$J-^O7KUQA!P_V7O@<>B()
 M"F'DM&Y(OYNKXXZ>B;H4,WIAQGW2V:_=KT^/UZI:B3(][KZ.R:>-%']?YQ^G
 MU<./L;K28$D"%V8EV63CX>3O1*M+%0H.SPVABT1,:>3?R3\77%WXG>\>6J);
 M*8?FH>XCX8<\/$IUN1;71`YNCHU^'CLYM'^TW"$J5O0QPK5G5/U=5M!TU=/1
 MTHE8\U^!(\)2\U-I;'.F7B*"5#MUG1X3;T+R2A)F43RP!(\<YOM6O?R7\-/#
 M81#4B*I6VIS0EK>"FP#0&CHU/%EZ5'.<W4[L+7FJI[CN-[D*^OG)R2)'B#*`
 M,A`T$.XX-)'K<\W;=OBPW_`F;_Y,85?=GX^TGY/G.3P?EZ9XZ]-H'L\O9VD\
 M4!_(H(L@GY5(<[A1A!06%12`,0"H8@3&**!%@"A+2V2YA]O*C4K6I92J+G&;
 M0P:%2:S[G.4YQ*TV:+&T,BJHE:BRIH60UIK56H6FBZ`79MMU4JJ];34L5554
 MM;55!BVH+;:G[.V@++6<=9UPM2RVERDK2T11HE$K6E+3*95145%;102I4JMK
 M2T;2EKOK\W&MC2K:U>6;.,)=VPY*8J7(N#QP.CKK1;+6JMQ-2S9/80#WDA9*
 M0!2=9P&8`F#`?U@?D0M!1N`L)(M8"R"HR-L`6$`J(DD!*`@K"V'NVACH@?"`
 ME@>Y]92TG=_Z3O8*/ZK[VP_\?J,H%H2,-TG;9++`<A_7A^LT6&O_M^^&%/=K
 M(&`^#?99?D_PSJ*Z.4M2%!X$]'W:P1%B(=&M;#T%"ATU1;/XM)_">@TO"!I1
 MYR^_LQ>1$>8=IZT(?O82<0%A$H_JI0K`K/BA1]=-N2:V<,8RT0A#GEEGCF,&
 M(R+&$0B,`0%`>72R\S^T1+IP56/P_LI-<DQ^F%B?E8>`E?#]WW_;\5E,]+W\
 MUW;!LZ&0>GKIW;GIK\1R^4WUVDZ&F=TOWUZ:J]2EO?=O\LT[W'2WSFMT;"0K
 M.Y6E?269H]/%_W\Z,9S7V8?W]7M^[\.CA_Q^N?S<?[;<NSH\'C\7E_;X?CY+
 M/)W\_\.SL\>/J^7Z?Z_5^GH\GP_/\_X^?U^@T_(:OBP7]<OJ^%L@G0:]7;LU
 MW:>Z@^3;N\$=U/AA^??9\WY2/7_TQM[YZ$%/>D1"OLGM^G^?\L,0KO4*613Z
 MX0/Z55%)/S^Z'51"0^\3Z"T&'09:D\C.4#&)'?[K-&+%I_1?ZKPEQ*9RRP8Q
 MW66<Y#2S-BH\FTR-BU.BM6-F7_NZXV;T75TXS.0O"<;K-\*6.8XEUA8VW=.!
 M"AOC/Z#D=9^_H'4]71S].D)5(5/G6U73L?4F/RH-5YN06H<1&!';%F_Z$=)\
 M;DW(#LS0C?^LUL2W2.H:E`_I-/4?D]`2J>#=9U,D*72FLZ:G^P\H8#`Y<A@G
 MGW>/(I6!H$!U0&JCM+M852J`E4(4A["$3'QK3?R]Z2"$Q4#]?'YN3SLGJIAO
 M.GWW_I0O_3U11,8HLQ#OIEV(>D:2[%<N]%:*,@E,ZSF)ZEFK^@\^A`C@P:6;
 M&\:5VXPLW_+M*Q>_N-[;>".(5V_$_N[.)LY\M2'JXU`%`.S^VH=S#->41H[N
 M97%*QCVXAE>1U9@?DDW@8[AN5!,D@1Z8KWPWI5RB;;+B)GNZOOU58>%>I:[<
 MG\X]"&,IJK1U%\.2A0>"N.,];'3I@6($Q!-:+)MBKT8N2"E,2M=@]1X&W9JT
 M.0FP)BXF*1K$HH@5BP0'C`XV_P*9AC_67-S_O:SG"B!4$#4-[0>L)V'766G9
 M8L==(46E)I\;6,>#0\XG(MTRY=:#OSE[H6L4\VYJ;"_V)?NLGM%=YD6:./5R
 M\\(12G^;A9MM(1$15-7#6ABJ`_T[*O>U-$TIBR@1R<_D[]7E\Z;S,>?\"H"X
 M07"&W"#:&+AM,CI`@I0Y;UT!O*13]/QD\DRL5+MIBH0R#Q65((!KY*0W"1W!
 MTE9EWTX18;L)]ZN9+I%]$7J"(8PT4W[J`.`$6Z&<#*-C@[3&5I`JT+F#\Q,<
 MZ6!$<B&GP)S=MRS,-&WOETI2%<(M6FAXHE%V.*I]&6G%F)!8)F_$"#50"VO:
 M0N5&YWY]\35.3QID21(&/_$P!I9,(0=2HB55(R".P\?A#=8W$#V_A\_T3/[W
 MN>`?`\7L,Z#G_M04_9NAOW80,,#J]T)YN;C0*4N&F?^^3X1\=GIH&N1^VGT;
 M*;WCM[=-7%ZO%7JH6X&]NDYM\DN3P?6;%N*&/0:@]T&>ZI["?2K>2>:)M#=]
 M=4#[]SZ9SFU3RY'CSZ=G'54U9H9GV;-G9N*=?Y:F]:6XB'I'EQ*YH#8I"U^]
 MVQV>O_Z\E_7?VXYTOY=563R/DPSB?[!;S$T>WV?-R'1U=FUX[N@75-!\,F`,
 MO;<&"&B=G418LICUO=;;LE5"L=$XS=V&,U3/1TSYY'/[WY#\6)I\S-7Z6;::
 M"$WU@L'[U8SF/:IO;Z8Z!`G6GMYB>]755B2/T-Y(['9QUI]&94A"(/1_F5CF
 MR3;"%_?/#?V:AJTS7B9`BL21E.H3FPE"-?6_"KLR\OC8TW>1^)V\Q0VT.0R_
 MQQ-IH8\1523.D_7RPHI4BP6)C];BV<E`&X3.PZ(S<Q='CVZ\+-?1">--$>9<
 MI,/UO9"W:?AO*M^]>*JE!95O+M?(H+Y_./UP??=A-RRMJGX]MAWS>&6!HVSZ
 M+2COG":.'+_AN%M&3KN'VVAS*:_#!C'%%^BMZ:8J:N0%&FSGT36E756^EFRN
 MF;/DK],2G)UCN*]%N-TZX3\M-,I495XNO)!H3,3V<A45]37L?,PWSM"KG:#;
 MUJ_C!K&7*33#W]=I3=++E+=-.C.^?EE4J!/+;"&GP>>)*RC\?%,HQ[1$(#[8
 M^C*KDM?H];GCC84T'"TGU1<]!O>S9YZ#T'=[RS@06\;'EHY3KA<8N3^5;J%1
 MSO&F%$:9-!R/?=7K%393`)!<;$))?%CY^OT"DYKYGZ9WB]YFC];>3O>LM\%V
 M`WC1<@9[G9GP>!\.>'A3:U\FI]J]];]>R,J[;[IH99SY8F'IWYS<QPY"TTB!
 M(T[9TQ2H'SK"PL-8F`:BAVH5R>$IM6O=`G,U,B'B?&;II;OG_GE)]MM#S!0<
 M69N5G0A"#JR[J.:25I.52/+MC8S>R1139+Q7WAX2[>>5VIWE=9BWK/&3_)XZ
 MH4)L4&*+/)&"40[DZ3>O5O\;>CP\K7_'=T\C3JK*BCS)'RTD5T3U6I\*5S9'
 M+-4BT4VM]=JK^+&9^E#IFL3,),D-<7]=CWQ\;Z;[91$1>%N_O$S>D/TZ_"'-
 MC72S$.8G_#36GM^CO3%,9SRZ/JQ5ZV,-!KYMX'4L9Y><X9Y(P<>?.LX4=BO.
 MO3"1I<2W(Z[7IT)]EW^"O6@GBHV>KQVT:#TK?ERSZ(E76+>ZWKUS?E3'&A9#
 MUCT%X-QSQ:"_L-_3S;R5:)-:SC.BJ*U>1`Z&'3'+EG2&W\^T:UAXT=VAT;(Y
 M<<)L;X1FDC9/D-1T:32UU=O3756]\ZFVJE+D2E#XIBZ#T].PRV/VI]0U\,"^
 MF(:]&C.;WYS!BS8TSPK,<24-T'"R*BXM;\Z5TF]O2_HS'5-`@N94KI7O\=.V
 MVNX:AU#X\+.<3D,RL/4%F"((7`@+)`2?B?G1'_%)$5A$.F#420#[92R$!@J+
 M&21$(@)"#%((C!6+&"K!D52(@Q@Q8P55BB1!`BK$B(*"B'KL`*@K!BK%6`BQ
 MB,1(@"(`H*JHD0!$`%@+!C(\T"B>RMD+$1441'I?[,)(?Q$#U^0/'A&2TM8$
 M%`D1A*@;`*A0A,0BPA0D_[')T(&D/Z`:(H=R56%5E9*R5%BF"G\B?U.9K3FG
 M;@.;WA-.T-IB5BJBHBLKIDFW$T,E"0_H2`?0D@^1%5/+"D%/^.DZK'"3E`4H
 M-8!8")_%8^T1%*61MH-(<DSRM*%Q,6*JH*%ER3K&%I8Q(P4AA#^=*AQH*'+H
 M0=%UG><ZGO9)#3#933<`IV)W%!8@8$J)*&:C`L$+[\Q,RJQC!9&(-+9K("L#
 M]6[`X9VLL;:B$DP$(?XR$A)!8((B"R0)%&'KI=4B,4L4BP4Z@0D(2#`@4`"G
 M=95HW]Y%20?R%P/P&E^RP"?3)58:PIJ!1K8D]F5VP1"OI9]"B3?O>!N?2'G_
 M'>@BF*IL8AF0801R0?P@%*$.Q#$`+B0)%9!$A$$81!'8H_>"&*<.BW#U'0GP
 M_+[\;.N%L>9:L[X'SC)\<B:7>>_QKU_2Y*FIROYO"5D9G84/UY8:HPU18&#[
 MNTH%_VB*WEM^O*^OT?CM\F+[<?R_NA^H.W$ZHP[C5#%,5I>.(7G5V7Z01.==
 M1"`=4///\?]N&[QK8`FX3MP]TC.+`9`6`G!-!W'><]@1:0FUG0>S8)@Y3,!#
 M&**VJQI>JJ8^%G@=D,"SL]GA.<T?G@?O"<]D`1>IL6VEG878X;E,1UF*JJ*Z
 MH56:[;@Z:CJWJ'R^/\;B)4%S536C$48F8#\FE]"1H6X][<AD-%)2J*UT,6:%
 M/,B:=V)^>,),FFP?<ONC\&HWDBB-FIMK:FTJ#CCWUIDQKI_Y/TF9@6WJX?Y?
 M\I_S@TQ\!!0F_TID4-,_ITK0_].=FFG'QY?-`$)%80555$1CP?"XB@**L$$5
 MBJSY15:UE!11"%4512=7KXSI[TP3&(IV'9L>Z$B#%GHOF6VFE+[Y<ME/X9>'
 MH\!":9K2ML&S)FL8L7J4N)R\-G`Y6C)Y(B$'%"$'2F'+SQ$!\NJ[4X78:V;(
 M0A"3"$D@2%HJWFC1N_):\(7N0]/CKH7"XY47C#8;OA=3K8*D<`2E'U1)`LB&
 MNZ=D^-)]&[?MET<JHGTN=BK4LU#9!<RU?("3>8B4CB:6<_6AP-=WLX]QO#L[
 M%PS2L>F;<3I\T]T$N:55-'*QBH5%WYS<]$IO@.3\&B9&]:A!Z"F?595Z$&MB
 M0Q00VSHQMC('WT(0D,)H%!+HZ>F@ZAF8<Z)A(`U]1S]^QC:]O>3J%M'9ZE3\
 M?]6,^E]MY'&C4QJ.1O;9YU]/3FV_P6$"UJ+O1EW[S1/A?TZ-.QI90=<E&K(*
 MK#Y8D*@H3!L*_`X9X(?"9F\Y3?U2X2M*<:/$[;6G9E,6C<T;FMY*$O]]'//M
 MN"\Z;S6=^QR>6T-1\JLK;JTT%N*4XL^&#EO`&*>FQJC!J["9X2-%UP$S6UYE
 M9P8J1Z5*?P+W0YN?<V9M,L#`+DMS3D6H$7)@#S<X>D3,PE,1-W#8'N+\C"<X
 ML;W("$8MP9-'3'(B:P3)F3-/O5'IK2E'`;DHZC-^\/$$+#4:>?K+<BY-)X<F
 MBK`GI6)0:#!:B:-/3+*DY2DTX;`S88J3J'0]DS/,@]PC-F;CK%M:F^G,[X/+
 MD3Y&G!&USM=!+LC=,=&O;IJ*64Q-DY<2T-P/NY;;DQK<LH%;C#99S3[Z&UMQ
 MVC%--%'&LW#&C0QBFF$V[$0,Y0\TS`^W*3W%+3(Z+,L)RRN>J172W@WS'/Q8
 M#9`H@'@UP:)DS8LT!78HNY,VFVS3:QPU%<VCHKGU-JA9/N@[WSVUUT.7(W:@
 M4-"WQ[E#R^@H:3/F4"2,O7MJ"'+OJ1U[DINI.7XQX(S4O<)TS/LSW9?/,>W3
 M7YN.1/AX[7.W<88<L3&@HB!NF:16B`]E<^SYRV6,SHW%.EM,L<R1@5ZZ>G'Q
 M3WW)=>=W$EILD6%&^AQK[BTU>KO/H_8_YG_%1^-7FDRDU:<J%I_9>%,P];N3
 M;]EW=ZPL.]*.*L1-5$%TZO:%1U5%8O)3&+P4P0Z>U"'KB8>ET^$[5I7$]O9S
 M;T0<V/]%ZSYYCT2>D!W^;Q:&*'OU"/9YTE));;167T/FO*==4.9G'R`_>`RB
 M]%4/S,.B`MXAC"\B.%RS!:RH:(!"0(OF#=%WGFO_N#^X%R0R($@=$`R`M]4B
 M=O[?WW/M)'%10H`O#Y8EQ_%SL"=IC0-5TJ61#;`#[$_`'@E#($$V&&1GWYHK
 M^Q95%</,'V,;`"R)"(6`*HJ?D_LZZFD(:FI0#!-.:L@)1!%EMS`V$(("')U5
 M01$$50@A.G7@J6Y/H]U1)-':>R9P(`I)N(2+0H&X#D>5-3K9_Y(K3+0A`&B4
 M1$K1`ME/5[KI9&:43&(,+D)],U=1B"'I.A@9$CV*RFZ!0Y0SONG7,#[\2G$^
 M4KR3##87+28URD/[E<T,==I74]$N^%'N9DG?0E!#6KD/V&&Q)"8;40-"XL.,
 M0L)C2K%!)N87$UP`H'3K)EYS/Y(\OWW=)1*?RVP%6I9K31FIM!/6I4E$X\8\
 MLZ_JI4^K\\'4MH+2R3OB7A(=)U=4VI%1T[DB_NS_7^5JJN2\1SAQ$EZQP1K2
 M&]F#B.:LIK=\=WD6CU7[4WOY^,9N_?5$^0D&AX$9Z>5"PI';I2=^U]DL[>-?
 ME3>'P4^YS8[N^-%KF")/"IA12[]";ZUQ6C;P]5015;:+6>3>S:Q/*8Z4D7KP
 MUJSM^?'[J4#7H;YPPN$0W(=/SA!/_J&1BKGS0^>!JGXSZPH_/8$^R?C=HH0_
 M.LFLFH)%J59$C"`8DEP4D$*0&0@8DF`F)(M!+:#:LM0J%"TB*`*#*(#;[.>S
 MSHM&M:E2H+4^020_1`_=/_G78&R?<))(X+N=P()/S\NGP^K;-)/+"-EN#$1(
 M9,BBP3.NM?,<C20ZR(!@.WB!<+/?L4!$A4*@Y70CZ$15_CV(%&7*PVL0^5/J
 M"\07D$!:*&E!BB5*"HR+(5$*BK$HV0/^*--8E"GZ2$!!&"`B2*0ID@!8D(H2
 M&1_.')I=V>-E/[_;^1Q/5$R8A#H0G,]%#<S*"RCN=R!O-)Z6$:_&P-UYS?.B
 M$#M@.G3>`/]/[HS&MOS&%OT:_VXR^!EMR-;B]=[`I"P?-$*BE02@1$)R@=J8
 MA0U2Z&%DL[C(9#3`7?!6\!61''7=G*_316Z7PK$H1LY4;Z);?+H-M#[P!<M%
 MP!(!VGYQKH@E'UHPY?7/)#!*/B/G_Y(-9AFEXXX)`R`Y1720\PA6%19*@405
 M2H2=P0JZ#T&(3JR+%@+`%D$9!0'[CM3=1-8T?A2"V?/R>;9^#Z^0:Z73N)`D
 MS"%XB2(A*R@G9A51AB0E_%E^P+X>OS4[^YR^B]&?D^/P>=JJJC6JJJJ?BAB>
 M7DA[:>]A^]AX'7LLAM*=+\PN>3OSS;*1X5ATQDT?Q8_YLBVAZRYA&^,Y'0FE
 M)M$Y-7=4F4W7K6*=3UZ&.)XZB>*/O.<XG43EW8Y9)#E#W:,DMDE*BGB<[+*.
 M<&:2Z+W&F[2C.6<S*V+2Y29^WDUF\G1-?"WAOY5"W1,8H&*<W`QD+A3KH:UK
 M>JG?32U@;T6R0T]]*DM0Y'EL/M?;#85<C&TF(+K//E:U##5,^KJ3MN>-C]A#
 M,&!'S;M?_J@$Q%XB2ASS5[]@Y=_7(OZ)DAVUX*DO77/:O'4BG>.JY6UC&-WF
 MSUSXGBK9+N2XZA'2@5COMRO]J.XSKK"?_8L05$@@HBBB(Q9%9!$;/M"XCISJ
 MF"WSLT\PY!/;G9B9PTJS@$QUCG;55<$Z`%<0(8*TEV\([UN'+S%<GZ->=7Z0
 MT1$>2UBU'I6KO,[\*"NE2Z9M7FG$,;W&8:$S!CHQ3CZH(B[TM!`A$P$;SS%6
 M=9Z6-N0'#I<9Q*SCRK6U8T/A^\DX-D^2PZ2%8=G)8BY(*[R>N%[^TFX(;0R`
 MIOQ<3H7V?XO'!V9E'<TQ>_9MYCI#-Y@:L6-BC&$WBF"8'9G.R?+I.-8"T58=
 MDSUKK?/93%>Q?3:]$MQ4>:U>\]E13PUZ7E-N)*,I9##(V33--V"M8%0?7:[Z
 M57K7+;C=MC3.+W(]U$N@<'.@6YL<1&9-$=#GTFJA1"R["=YJ7DL9T^+5$D7G
 MI^5?@N_CZ%G$C_<_#QRI)A@J.)T@?^*,J)_N@0\4E@_C[=H^_-;,%T#)?I^,
 M:-/`5L-]\,;IRT@$L"#:CK[)@_HAI0A`E+W..B`D).[.Z,(?3[7(\#R?YL.L
 M_7]*"R]DSLPVP7*86X1[_?=`)%P,W\*(0$IR%@H;!8=B9O!WG=`#PLS@>S'I
 M]OLZS'F,N7#-O:YH)GYJ'A7^D?+CJ_:)9/1ZN'ZM^/X7%Z.Y!5$T;+<I31NL
 MTPG[#;9&.JC^;;OH1$W_1TZ<;*_!MTKBO::Z+991IHB\]3,5)C\*?']W@Z>3
 M+9/OOEE#0U3"4VO7D%RIY#R#V^;4Z4]59D>AZ_R':9C8[LO-YH07>G1O3K>\
 MW6^QA#6[AF'8P_=#G9"4(2A";&,&BBO%_SZ&USANK\<">I'->0@F?>?7:\JE
 MA;EIOA(Z*.JG?*&"=M$'E0[<D(BU9/3A6"X]M]?XEU<*I/<ELK3S/E/-371&
 M.";+K<`+4,V:;6CDNXS,W$D),&A:BV7D/\2V53]'(TC>*D=SK?F#>1,'.2HB
 MJ`?OYXH2(XLYR2*WB.^$I]?5RN*.>#LIZ3$@=D;KFN!"_O=Q?4[4A+5=%'SL
 M_^*`@5::F\>#T,/4KE5J#6OUGI0,-A%Q,43!Y:>K)+7T3,/5^:"RT16SFF7F
 M[ET54J5#;@X&VK^=6<JK<GUG!`4%"\$B$_AGPC-*?9Y82Z.WYMK8.78+/OSA
 MH?:-L$2_LE8B(_;A6/8VK/P+,B-H%HR';-,T$3:8LT"(FM-D^`8:5HYTVEI8
 MXUE$:+8JH<+5J?NW&$<ZE41HETX0S,3)^,J9HHJ'9S4;(61,T-B(6?5#?9.E
 M/$:S+MD^-YJ<)E<75U$E/V:(RH,)RE=E?9@]E.<.$:#:CV(/0B:GC#&IVKYY
 MR%FDMHCHX:\NZ4I.Q.F++';@AF#LBFS;NXW*A\/A?IGE@[5ENBM(XD,%H:"T
 M.^Q2KDC>,GA-GIZ.GPF^NSL=<:+26A0OI3=NCL&='N`I\$*5FM&+TT.SWP@F
 MQJK9HWB%N=[(\6[+.[=HSFNURQ\'3WUQPQF<);>>NR0V*V+<M,79)A)E!VTP
 M<>'O@>SC>1NNWN>.FSOK;7-84/V/-/'7X8T+?3H\SROBE#GB2^SEG<='I\'8
 ME-[%WEV+;/L^D&JU<X@A2RA&)V<HSY=<\)EN$F$&M#"JN>`9(8T+C6YJOJ>?
 M3T]WZ\>)X>K8'0W.[A-<UZ5Y4IM(61AEW)$K`S[KER&*\EUK\:)_O`&T$W?=
 M1(>V(_X_(?W7^'\W]QP2`JO_AB+2T;6I(RD11&"*4`8@+42EE0!0$HRR?4`,
 M_M,U$6#&6EB^5EU"+"32$(1N70MX8_S_C?>YH"63*F,(&DT+"XLFM"*J6R%&
 M,1@H*(BB,1@L%D58+!)56`-+$9@V32%FH,"H%*4Z-$FK2*$%-I!!*.E%%40E
 M21I8[*1F*JJJT(=1(1UO`-(C@R8X,4*R$Q$D4M&1J`(?SY?Y]!TKB8@OU159
 M$4/\D-%'L']44]_N%Q[_1R"PIK*@09)<OM:=<0AD$@0'=`3R\OK]6FW/2,8*
 MJ*$'8>.EBC_^!5H5<!5R/D_67-X:&E!^+=\A_Y)1+'^#X'N`P%_WHO%ZNK&B
 MP.Z:;=<"R)K_P11_D8'\P32`D@A(`3[5`_I'\R@P_S:+NXX<T<>D=1Z%K:<#
 M]8`E@%L0I`3$-2F_`-XJ&TB@9ZA>0($#:<D:(`;S@&`CBF"4@4)O5-O2<Y*$
 M_S(S,'[H%VT,T?P,XDPC`_\#]'@VO[DG_I<2ZBF]'B8.<.!`;Q#;P/TTL1:@
 M2+3,E,]O0=.QJ)YBP8'7B:&QX#U2,'"QKF]-@/,<+1`UA(BU"3V=J8-&2X!,
 ME<SD;=&=U!U-W3TSQ@0C(2$PR?Z`;2S88._+56@+[C[,3S.ND*+8286#;P$]
 M@\,8ZC1+F0<("'H6(&Q[0W=ZWYHL5$05458`L6"B(B`*"A%BQ!D/#RX^!BXI
 M`L3HPHTX9!0^=Q"OD8)AMQ$ADL6R(PKM(&D-083:"P-,&0MB,^D2&&62I;WE
 M<]H\<A9EWR=3,.(Y'$GHOP[5AHCR.!,.\FH=TS%BP@?5,P88[E+[-+%X/_"<
 M$OHKHG3&09!UV<DQN+T.N<3G5!54-I89$A']5T+Y2TKN*VV!'M6B?MRB,GZ+
 M6`ME,(H<L[>G7-\;WJMS1N&2'8PX$A4I\H'N11OKEL\A"=R]\P4(BDC88I)A
 MF\?@M3Q((-4WFL0N501(2$B=Y@3J=P@^F"O(O0:90`2V_A1#/%"[S(<X+U<B
 MD`Q78VVDD9+@="BXAJE[N[HXTED`O12G(S#D8(.V/(.DZ807I5-]'2=@YKX]
 ML=A[T!R:P/Q]H8H#L#''%MVB'FL.`G?E)_CT:SD=A/`V4[7V:[]UZ7[X*9;*
 MYSI\#09B&M,=IUOL@QLV,#$83'AY2H3U#!&*",!1&$44/M/[D(<='5!CH=C2
 MI:+4[]3C4(3"[(C$P@;\,EA`R8HBYZ0]8<1.O7Z2_5PN[KOFACTU@NJ$\*$)
 MVY&-MN1(#G4IMG9.9.V@SY>A@T=#`LD,0,O2\LQ^;TG/"==`:WT+*K8]8]9:
 MP1+:4\;H7+$1HR*`$^Q[<<AX=$DW"&^YGW($G;:)VAH`1A^4\]CGFI6VK]'/
 MA\=G!V#WM*8KEJ[6552VM\"ZV1J8VUK#+CUU7<S-;W<LPI4UO1@Q%$=^!<5&
 M(HIPVW27&XVN8,+1;4W-"\2'/WI#WA\"E'>\46`:G@<34WKF$Q-K6!Q01^0W
 MF6&[,H/H=#D)(R$B$W:'6A>R*P=!QA-QF"6=9&P9B#MF8LTBX9@-LZD.G0VP
 M$+SI;!(0A[$-ZGL^M#,*!!;&PY;S"H;%0P0V>.&ZWF8E0]."6O"4/R&:7$$I
 MVB=BB3[FHL6"Q3AJ*M?J!MLQX#H4U`50"?E$*R$56TLG./5"!VX"$]:')HDY
 M(#\,AZ'V!#X>-,Y(U'S-E`<L2^Z3H,!!]L5,(@,DW4JB&WAZ?.Z[X@7-Y@*;
 M3;$RN=#S"AJ7W,6CS%!SD&D;RZ9<;/]E<J/+'7Y/+2*IKN?IEJZWP3U1R.*]
 M'F76D9\Y)EZ)"=TOD/(P[1V#7LDQ38[K'J0%_`6#:NSP)Y^%H>DN6!M6XTLJ
 M_4$#R#THW(!`1BH$@I(@*%4FP>;N/!Y@/E@L[,<CL(#!HS#>(>U1FP%0P<R0
 M[F^)K2;EQ<^7',H])D(YS_L$>'SS"U4W[HQ(;G=YNH@W%`19%'W#MG`SQ)AH
 MABQF!Y_;0'16A[HT0;H=:]HFT.@8P8081D])TG94(DM>#Z]\FIR+KKR(`\KQ
 MI`SZ/YF`2#>`!%F@?934Q]:W<[L&I:EKVCXAV<]S-FF`-VI1L"L.V&'=X18G
 M3W4X#\0\,(/H_F?4>Y\XGF^K5#</S&@["X3R*T%B@NT4T`J>8B)CEK)C,RCJ
 M'4T05B*/V(3D2R]`;<[:&@0LZ`"<"06A6M4L&`6Q%4^V!("O=&B(`=T'OE21
 M219!4+P5>Z#(-L1V$A8I#8[4%L'TC#!B5$`\SG3Z+"KX04+4$)F>!H^NRXEK
 M/Z_W2_XC!,7X@491!8@:A[4`L)"0F&ZL1/.CW??2+S"_IR#/PS"/U+!$LAJ+
 M%1*(%MO*;1R`-)T&($!,6,%@P7YWL&:SQ$-2&W'8ZAS"8/$.5>DJPVW96JJ`
 MRV=J;>R0;;C3T*F'4VR32750M7`A0,DAK7VZK`W+\2/R('R+Y.!H[:)7;#-S
 M:`[BC'QDOWC$,:5"Y%8:1PJ+.7#KL8<BM2BK*^G(X8D,$"48)<B"WL4U:GI+
 M_+-N.D>O#R!AM@>!"=,RPB&PBS43U#N+;@>E,%FQY^F<U'%Q-F?G-MR<54[O
 M#*,JCNK9M<57S,2IV1%Z-R]9<&1&0@L,"3,G9DED@K)/P(;/<=IGS(Z`=QM2
 M#$P+$2Z`D#436AR(0N.T7L[J`R)E0[\LF:)B8%XBM``8*=E.09^";7>H9CAO
 M#[^X@2VY#:AC8.)@":"R8XJ`(H*GK3>QL4;F,2V;[\`^">5BW90UV.\HD"4\
 MM<J-+!T-77>K=5EM4ITMFH9F")H#ORA@"*R_.+UX:&8/9O&_ARXYBZ@V_V"G
 M(Q<>1CPTV1A!Q539FH&S#`#/.^/H#+:9!L*L>][==Z^.`\9X32%E,X%UJ!Q[
 MX&W?AW9M,[,=;40;`,62O*LC/6*B\$S!BL%FLM`AUH#9=.8)BHPKF0-)02="
 M%$H7%/!<3BW@/:!38:H?A-P2N@PS)V>DE]1-T8@2,=1:&T25#)Q3LV@;XB]H
 M-T,(#CV/D1?).Y7;MO+=]KV\B4JX16,`"Y8Q\-DQ/#+KUU@/L>IE=V?'VPV"
 M>HDR[7830RVIL5#P0$8&VI*2+;!4="2F],":LXN;:P[N1<6HJ]T$Q3`"K$=#
 M.XP:L!QQ+F:0RS0T;)F$",%811C&<3#C-39H#W83N.>]C)+>5VY/IM"RX@/0
 M#*U("PQ[VYLS"9RX4L:@$;T$VVC69MK"0Y,0C?$>6%$+W]+=3C[>]ZH.^JD%
 MS6"_O^'`?'?F',]GFTNS7<`:/D2>Y/G+1M@-6R`VA;9\Q`5/1_/]=+_I0GEV
 MB]+*561!1/Z?)0MZJ+`&C3ZC/-]X;RX4MK4MG@5<S[Y/*O=G5OIG"G&_2XHQ
 M-(*^ZD3$5;"9&1#L'S$!&6VA;/0GZ_)Q#7U#K8>(YA,VVY?:'KVOM.M]=U.4
 M/VBB"(1$.#VLI)CXR(:)O"YT;)*JBH)N.VB\&$;\&(:JL^=ZPYL06#(.18$#
 M(C3DG'W;*[<`RRV:OTRU=4,YFQ8/>\X$")&Y.!YPV.]?7MAW>)],Y<5!5520
 M4%D%4&U:::ZGE,X!(G6]EV,[IP-#P@#'*H"<C\@?G`-),!K)C+T4!:)3$HB.
 MA2(>YT8:T`Q1^XQ#([@N$1__7EUCT$2H#1$[1BQ""?`8$#ZL]DXUB[)'=R*+
 M`Q,8H=OA)5U*<!BCY:J=FQW=/J+5X0^XU^;]&G`_TF28G3#I)CO&/K[V/Z_R
 M_;H_)%Y-]"A0":9,0N,(PDQ.SI@?!.#+_<[.)A<TJ-`7)C5&R:A0TM8Z[]K,
 MSMN\BBS\9AI<(T3"=9W$F^?D3QM)24](@(ZV_2'2;09C^^QC^E9^.IVF8W,U
 M)1OQW:D;MIZCKA4@>S)@N7W!9=2XBX"SU_#L.`\Q(I_/W;O/_[(1HE:7+H3J
 M8)=_V66;#8(LH,O_0%#-FY8_V>IH5CL>VKKCH]!7$K>,'6XV5FX[B!0Y^>V$
 ML90\'?=8>F>,R_W<P3D14'7=CJ<MU]'!<O';MESGM7#^0,Q?M^R*"*L81%/T
 M0]_VU/X/Y8?.AP#^51/&]/]88UY%E3`U_)^>L0,TVT:E+L^.&YQAB8'`S#Y"
 MOK$AA/PQ-,8#)P3VD/T[1=OP6X-8&F@S^%<1U?>9G&Z=2"[!_2<3%+!A4D#&
 M+^KSHHS-*AP.;%#ON!M%V8`88+""P_:[D^^>L8_3`D"![Q]EE#M.9DV)#2\6
 M0-39L^?4V@JBG]'&_D#1.2=FGBW^$/>$GS#\'YP2.UU2Z&\WPLMWYJ#7CK55
 M4:JJJJ145P=@#^A!.%!`IYG]6)0Y#<W.H[]9,,3%1`P2)B08[$*4_0)@;!L.
 M(&\IR"BALP?TB$0/Q$`FAE091!B;@WFJ:B6618DVNI(OYE9LRB2K90E:<2!R
 M3J2PG2(D9#]CTX/T.@.)D1#0@_5_FG2!VP:"+WD2A(B"SN<0/A.O?^FU;\YL
 MX[;""PVS;T;[1QF.]00S&0OR/4505!\PJU5+F+K9,-9XIHP5A?RV0H/7`G?Z
 M@]-VV?NG,9DX;`S@;V;?FM:]3YI%-&Y^P/0443B)OQB!D7B6]A`)ZS_0R,!@
 M)_VBA[B&8'[?6!7*/]$\:M"1O)"HR!H1CPA]T"63GP-@H%F(A`Z5'H2"H]J4
 M0SA05.EKQ-,!"T0@!)"&1D@?PS)#W/6H:K;".@0+'O6R&T43UZ_F7)=9Z"AR
 M**9`M"*$#D2R=MP<0B<`\3'SJ"6UI$5<]T!:!#O8';TK,!DVWLFC5*PQ413&
 M"7!#4#<^P0GE@!YQ'SZ:$@Y&7GF_BBF1D(`X^.>N68/JJDQ6\XL`46+)4$Z.
 MZR6'.`H%2&.)@&Y??!,#$.J"G@!$`3R?4/J'&"C(IVT*]D9*E*7NPPD8@'4T
 M:16`GSA2J@P*DHP^*<LQBH(C%B0I@WO5[Q`*(GI'M&DF6:3T<B6:39Z#*AT*
 M@EG6)3UT3.@T+I(U8'1`3H1@HDD8J,`C&,4&00(.W\Y`-I\H[C1$XL,Q,0(L
 M-MMW_V<1M5#26093FAA%T'WZ">@=$QS[S&Z&2G+JEP/03Q&3IE66R0WSQLC/
 M2AM-\9A;1,2%RJD+;4.Z&Q.M]0G27%ZP0@!R53:I(#$@+J4'?8["_I`(A(-3
 M>3+3),;2MZ>+,R+&ZHL0LN(LB>H)(>Q;Y!#&Q]7:G8!,2'(H`Z#PT5!$(R(%
 MLU!`1DS,SEB9B&0N=U&6H>2PR&$MX^,(?:R<&<3XX49,:!R'>@;8H7UL@'L[
 M#,OGHS"9QJ`YIEIM(3-"P`"D&`:Q`?H+EYH6%"JW`7#.Y!2+,9#O$(.#B/.#
 M%IJAC1FAF9>=5$=L)#)\6TBH"/>(H^R[%DWEA@L:A]%M_N^2OJ/BGI+7)@=!
 MXE"]=@.,PE\;FD,'^C9&RI]<7,>5*&"#`I2$">9-A"Y@?_BG`:[)N;&C4`4#
 MQQ51%$1%5(2X]GR4>TB99A6<2`:O(V;5`_U">\(*2(2(>IS]1Y<K2!4,X6BA
 MU7I2OX_+]\N!W(XM&?0)`HHL^@1+F2DJ"P"J-U`41N7KN!T*0U!B(><\/Y$8
 M1W`>[(7V@B#$W,XU;'!DU@4(Z)[X%[Q.1O2A@:@@:40#<W$INJ%-BZ#"0#Z#
 M8]9F<0_V+]9=@,6#:`M$OLTH3B%JQJNZD/>C#,7-.EL!3Q2D#'RS-PK</I*1
 M&5"["H6(VH#)03ZR2)?W[P<4MU^WF67:8G!+1];JC&,]@TTM-`L']5EHRD#L
 M3X&-OCB6"W)R74+N+X%:0G2`#G$1R&YT>V4'UBGJN4/K>5GI9![5*84)PB,3
 MQC8I06D^":,^LDA4-A6,9#:,%%(B=E6BHB,Q*@JQ8496M85Q*18CE"@D%@LE
 M1K0+$B0ME!$A&$81\<4?C]<Q,$;AMAT*0/^Y<R4-RAQ$Y(AG"B0)&I(#4I`E
 M1`'+(X5XQ\N&4M5$&V8QX!)D%7@GU#+K>IUS%K%)Z!V%BW<BJLLIL%$L0VW]
 M'!Z4Q0)J="%4Y+ZN#8@<H0[_06`]6E0&:)[8##B:>QVM8M!V";,!PS1XT(E9
 M$O*1T#QIAC%`0,0HB6E"B`L3LOQRKJ%)42%!C!(:)J)J-LR&^5I#&Y0ZC^)C
 M%&2?F^",1]<DH9WW0,A5U=8DL8'Z_=/,Z!F=!*DY2Q6(+1&6P<=S,?BAC(I2
 M$I,Y9*(VG5S^_KG`SIV_@BC[Z=R9\3TW0+$#RF\2C8'PLISFRYWU1F\M>,PJ
 M+J0/@'J#ME;5EO7W%XO(]H<SP522!%`T?8*9I["\!A!&"QE0(4,BN,+&@R!!
 MNN[=8NP39-6L6PJ9MP#,-RUQ<-!]G*MI:BZ;P)N0V2'_B20#8M2TA3XD3SX8
 MP#1$L)%+K5)AJLA63R[:&N=X'HOT]#G-P1[F37400;U>+0/2)"XAS062&6+S
 M:J<(-4CQF%"_8)I*9GIIHDW.A0$L82^2;;&EF#VV-Y0#@L<-+4:C:V-O92%.
 ME*.F=PA6"G&89'4&%$$R4CU421!"I)$U"B9IE@D8=RM-2Q7T\<C","<B<F="
 ME4Z4UEC;T$JF!F0I@T8FD65"AF&T"Z0M5"4Y,AAZQHR=$BG'A,#D-XT1B(,F
 MP"J-_GAJ&]'EV<`C`F@F[B;'CSY76&V>+5[XQ,Y[RPMP6T16D#"*4QA$X;:"
 MT&0J'013&*7OB%&XNPH*!543BUJ2G#29F"PVFM]27%.`NGO9-1EB3))JT9E!
 M#^_EVSKGDFD1-YN0LI98,OUH;AWW.P_Y6;V,1W0-?]@+!_(.8;]D2>?OO?K!
 MRH*]OGNRW0/%-2)P#"43NW_6%G.'4#2"M%PDLT$GO\_:<:?H3YN[C#:'X$5J
 M'H(([27FV"GK<XKA"%6CH[2!8HVEGX&PT>+%*)40J'`A42J;'LQ7/XP#_NH#
 M81^8B@R2)A_E0^UQS$;0XFT@[%X6("=55'MJ1210D0A!PMS4AU!HA9#%@/M@
 M%OO`7<-L.<P/GGM]].P3&L0+!1``?Z(4=X'DA6[HQR8G(ATQPQ0VKQI9D.<Z
 MPST^%Q82"S*2V0Z(4#*-,AJ((P6"PW!GHD=$"B&SWG/G'/#KT[9B(AB41>MD
 M[[9M-$<WK":G;J4"(7+E*WC.>GS)S-`,418![]B.BFI<@*#0-[C4;?D6*5^Y
 M#@"1X#$?N:$2C30MS]G>D6B()R,U)<`NAKUJF5*J@26BDPH_;'RCZJ,937=G
 M2PXT']D$17.*&E3ON,_DV(G1AAK,Q3T_:9=Q^E#;(<A!#)M5'CBV]#"=>QI5
 M)L-6K93M,1(F>%J,W+:E1$;C6ZZN(.&1OA.Q<8Q"'2ZV@]KE%B1`6,&(+%%!
 M53%5$)4R8<&ML^7+/!AS>KG?!WYZBIS*,7!]%8M:`*2/"S'7*O>0JUT,X"`C
 M50&$;*:;*(=PL1SR\ME,US*TV@EFFI>!Z&(JG3AJ9:-$+0`-GT=^;;UV037!
 MM!HI$;K>M8GE<>+[5(H&TZJ2R*63"T'@07)'=S2+EHK:$[;0\)U6$54%;CM6
 M6AL6%B)N\B;'28R2>%LQAUW=./<]7A.KV/`S.;E;(M#Q0WJ02B0I>80S.(*,
 MM"78*O>-!:6H.79<E>C:UQDK*:V&X602+&)WOM+<(VM-99L+4X9#RPJ,1#8<
 M45!Y=N>_IOXF=9##="VQ>N'0^RD>',)I(')<@<ACFHF8*(L%R3=_(&?;^LVU
 MF@'=UN]PK`*9-[(&]-5`4D0BA+5>@975,4$%BE0+S$`#MHG[S"I%1<`[R4[B
 M'6R6L$%T,]X\"0YTD@578A;IT"!W&:7G,C3U-6C8&5E0MQM(N^BMF5::MK,(
 M.=[67&%#IA-46V%]N)C63N^E_UXFMG*RR;^IL/6:!5AF?,2P0[./+5*&&([8
 M!.-!08E>KCETAA0<1X-T-1FCC(JL!14B",S4ZD1$GB/*0[2BV1@(PZ(((I&1
 M`B#&(40(&D=AD8%PX?-^K8&KM(:"L,CGF(V4MM28`:D4$@!43\VR4!0&5*I,
 M/Q#GP[:G7AL*$Z<^K_HXN&2T(:#*Q?@<:BE77M]HY(MA.BQ+V6G#UAQUK7>&
 MUAS0$:IG7+1V-7I&[NDM'>IOPQ)<39P3%^6,)5"U2*ZL5XO%_,:[#U'HPACF
 M,&)2I'+8&:IHA.S,->]YI>E(I`:*JYE($R+%.1$MMZJQ?DHAZIL/)$,<T&&$
 MO*;C:I09K^^]50)4,.`CCG<Z"@.(G1%(1#-V@.A$#[L.Y\/309KB"J9!F`Z!
 MF`%Q(]!#W7W5B6"',6IP_P-;IR(G8PID`.J4-E@P/>G%(;3L4=HB%U^"\CTC
 M:F@L66&5+00O/@M`E6B<Y\&373W'B>4/"?6?B>D5465*VV2VBE)1A:@K;51#
 M[R59:%5$16,$0&#T)/'P>P6,0\9(7J3&E$L8-(:6DUA!*6)DQK):$/=.Z3AF
 M#)#`"D"C`E1)UM.STC?J=MWBZT>K<MA,-R@)X'%`1$U"K$9W!LD*NFJC2E5&
 M,S7S?;G:P2,T*J!0/+I!#W11;ODQ/`Y&>5FQ+'[TI+_;B[WCYAAI3H3&NSV>
 MT0]_D0X<@#RRD632F"U'Y^,I)H@%Q@!:`<%Q\TP+!,\0U$(6$V]N!)J]Z<QA
 M1`A8+'O0`RVL#U]^R7"!PHZ+)PLEY(%6O5<[CA"R$`Q7^)92@YOBF;`"&\<L
 M%FPX4$)U5YG*Y8;%#1/(H)1AG*KL\;H%C=`>.EQ=<&:6@@9UL.P\B[Q,\S<8
 MQ6F##4`08,5%B039NAAF%2I3;*#$1BAO8<0*!K]HQ*PH[N;68$%#]\`#"+88
 M]"AV!1FI]?2/:>"_AIL.)=?8P&236ST0G-W.PPJ(=`<[QXO\\<_*QHD3WT:^
 M)I("5EXX';63%EJM88;"+$.V"JJ2\X_`\L4%G)J7-:.WBF9EONXB0LD12I,E
 M"E+H'0*[NN5!Z:%C1&0-`R-A`RX5P'@`B!!5D-S)OB0H&7&H2*9)!1I%W^@B
 M8#I\<`D2CU442T!Z?4<\BYX<2R&D01#IB<#Z1R#(@B)M0KJ,VZV(DN@IUG`S
 MXC.L=X(]#V$[C@^(F\6@\SX[VT=`[T*$H)Z37K5OUY4A"B`&[R(A3YE![/A>
 M>Q\]0($!Q.DQ7\)^O/W%ZIJHGX2&\\T0_:$5]1O3K`QGRD`4E#YV#`W]%RBZ
 M(J8;91D0#L0E08=OAK0T4BT-;R8$.P3,N3\];"T8(!#KADF.FPN\-QD7YC)O
 M!2;&5K46`PC3&51)E"T-FS;FOD-_P.Y5<@6)$$8,B+!D$`9$#$Y\G;E7B-EL
 M-(J*A.4A1#8(3CMWQYC?&4+)TM*%88"X2P#;\%VQ>Q:'HR:!,Q(C^G]3EA2_
 MBOQ/&R%S=4JM4"M_'>VW*8%D+["$$D+(6-F.FN08`-W_X04H#(HA&,4XL#9,
 MO'2_5+8&0BID%(4?I_!9A[C\!M2?,[?(3)"G#&]FQ7]$MU_@\GZ=]NW'\+/7
 M#\^2VVR5,\]-E=5EIBV0^CRG..==N#C;;;CC@YYVUW[3TYHB9A('F(^-L=,5
 M,K,LKLLLK\L`,,QV;1<%80\9=!(3(0DDH,:=P.\>UQO$3#2.;]L=<?=;+=L#
 MN"#?\^H5IIII79*I(FA9--/,UG-<N:/O%#V,X7#"@"#2N9F_LSH0"1.8@T)S
 M?2L0"@=T$A%*M[;3/@$=D'`AC2IKQ(4-&`=B4:.ZH&?[V=G%OEX:-D(19'BA
 M#S#>J=T0_2'[/)3%N00\WIC#R/.4+:#Q<A!3+XI-Z+L+#X`R&,`6!C!.<@8)
 M)-L.4"48$90@-DMFJ.W>XP,7)N?E8`YPY3%&-XH9G0HDK&I$,L,&0HP13$L$
 MU1,Q8J3`U+._6T`V&QV8)39J_:=L[<`Z!*=)#WLG5#:464I`J2H83]Z@')N6
 MFK#B'G$/D:"49!>VX>%A8/H[\RU]8<A1@_O\U>BIDP['%<#_8B4]OF:;.2E-
 MD\H&&(ZMM/;EETS6LL8DJ8/9T*Y`Y?E*L=E]JAS)/GYL*#ZOS6)#O`%A`Y#S
 M]GLR]GF?E6[HZYSL2/67_BG.$K%5^=\`._JV=@<LC-\]](]Q)A,"]Z0[^(E$
 MLF5=7M"ZOMI#QIT%/N+GB=)#T;XGRHT\B#BY6X64L68,HYF&15]`'$P`P`Q&
 M&"IF01+B]J=/O*)"8=L9^S+!SJB<&&EQG?=DN&M22T)7XSS;4##!((HP6,Y$
 MFL)LSK>Q-&DB$1%$.D0^+)\AJ%\G&8,(%D0+2A&02H3@%N.!,),R&)!@B,4A
 M/UP9)"2R!8?G]M,(@*`B(H@@7`]7W7Y0W(<02`B06!%$0001((P@LBBDBC(Q
 M@PD60$5"(P#W!-'SI@=V5'")+G=0*ZTC<_7M5-N&/HE(OW$%+C$P"&R6P:-]
 M!94AN2%"&C8HK&"HBL%B^$@;-&7W)P,;Z_4AD=BX%2N.Z\(^N2&#W8C(6@"3
 M'$E0Y0^6U6"I"'S6,0Z%#1!/!2>@_JVU,Q[VYY3!!U$$/<5L!]#G/)@),R7/
 M(<*5%)^T#/X.P367:%34DI8BI0S(7"$I>RR5$4'[H!H`+&0(@@!`A%?30.[Z
 M4$HZ!+MK#<Z62`*6+0H!*3Z_HO*-R&4<8A4&0O6Y4^(9+P%0[QF\_D++&_C9
 M,,'%F,`75W,(XNU,,.=3I9@.=('#74ZI%DJM!=568JJR%KZ;=G$+X]I<V[YD
 MU(D-"C#P9U6@C$S62UX38=GY,-G)2GA3##H'.C`11B*"B9)<QM>I4PPS>:.L
 M-LS>+6[,PQ6F5S<DDF7KNXHM;MS';:YGDC;,6O7D[A.5IY%XMLU#'`IK;E52
 MJ0TO?C;2G!44;1:K2VO<?1\#F!T/A.G33.CEM:-HI;1M*I1&!9K(G7-A1HMJ
 M4K2U*M8J![(@)^H.MVK!"$4>Q**:4B0HGJ9)X`=J!(?S![X?,Z8?YL#,H!6H
 M5A%)1%)*R$J+!0@UJDHR+"JA%6"D,185_>1%156`5%'5`4K(J,D%#+10,5)4
 M&V%04A&?,,G$$!)#]M`DLP8^,&SHIZ/.H`2!&)WI=;/8;X"P\24+`L)0B>WN
 M%U[]OV46#$#L`T%^L.LB>A4[A@!(2$5I0]932WQD8<CP&G,U-F6?@K?J4R`$
 M;!E<^Q"&_.GXPD"=M*(&)/#+!$BF#`T:!%Q*S.^0]-NM0P9(@7#`X!&$U-3K
 MG8@77:PY?;#D0L<&!2B/)ERB0I$2"0I^4R"3ML*>T]R%`>@E8Q"S$F)B!Y@.
 M8!K$RR3,Z&"(!KL#!>V8=G\FO8N+.24Y&<LC14,'I8O-SS^@O!3>K&IR"KQF
 MH9+B:40S>Q@<L4+(HP0P3,UU63V2T7>MB$I&JF:A?.X/63KZWQ#:';;P9Y#`
 MOL&0U(AKZZ%(HK;8C5R&(K%6*JH,Q09/'UOUAFS12J^6HC$HRTL48_UZ#`(#
 M"3#`"!$HJ!PLJCZ;$*0.A0W?'`+IS^0UR.;&*16+%@1&1-2BF0D!3M,E83:>
 M+))X&#?F=?N/HVFH=X$>+]'HL1("("@+`0/&^+@+$05`L3#I),F4T&Z(/&(Q
 MI/X$"M>IW.3B&1T7<Q6,;,S;MM%A)"*>6(J>400X*$1$80\(B%S/:PJ'L(45
 M1ZZIIH&KUX(>A#DL5838,YL7SDY-4N,!YB;3TO@W-3.A9MK/.IH\4BC,`U)1
 M/8F3MO@H'%W0#74RD!D!A%-GA0MR``FG5XI^(L=!E=+&7I.Z&Y\V!WA$G;RT
 MLOJWS,VDZQSUJ9D-L;89X'%W$.+\J?/+9\IJG`E'0\&%$H:LIA?E^2'!,S`@
 M=6-I*<J;75-@7TOC=3WSG*JD_+,\#:&((P05_&RD3=`L@TT?$#MG=^KM[Q1+
 MJ[:-7;LIUBUB8V;!>`82K4%R@O)!A@)E$X8^E9`<J`T0X`U`(H4&)ZAXXX"'
 MXNZUA-T!FYB56^JE7>6;056.Q&"#^>01(I!&`HB","V@H@K):6@*W[(@`&,R
 MM0*TI2++;6VC;4@U%56C918`U%2J0+:EE95*U`M!?C/GA].X70<0]QM-(&.,
 M?@FAK?8O./$OV&;N;'D2.V#&RM9(.P[$-@N=P(2'I9FK((&W/^V8^!PA?C2]
 M:*&;_/ZG*)4/E#A^=SO,YEE?WS_BQ1IP?UWN&BH12"<*RNQIO\E&28R%8DI0
 M:^%U&5[&&A:UO3RS3A1IKZQT$UJI7AT"=F[PE@:U>'4E'=@78<`;FHGD=1FP
 MXWHR%;EZO'0O4Y,,VPSZHSB<=G3@S'#$[)03B2R5I:?AC#>!YNW@V=N-V,/A
 M\$51\EE2(**1146*"ZGTT,%H,3"$2/06%`OO#0V/=+!9AO)OH<A#S-7V.8BA
 MY8_V?^MX.@=B8@-('6EX5&M!';Z5WK?#.@*9#<48A]Z`R@?NQ0P+B!OC(<45
 M58R3['T-@_=4Q=<F1JI;>X:)K.N:-XKHP-<V!P??^KSSZF"D^:TT-Z+M(BG1
 MJH>#Z-=-">ZQ:K#1\K"\`X.9J(IRC+!0WPC(0CE6=%/8`?0F$D^`P*'8\74Z
 MG<P,'=NI\-Q*&202UJW%25XAJ@G7U!I<*;H^$`QF"'(A9-)@$/OPR?7NHF\0
 M.@'0\$&2H%4:&$XFG"RA?QROC8K6KJD24?DQ]Y>M;'0<#'48"L'VH&,^T>\(
 MLO3.E6)V556KDV`=IEZ)*(DH>?(/;^@:U>84>3*,4+DHM19J)&08/$-NZ.[<
 MFILZS9FNM4Q2=?4/3V<+X=W[E=*^S]HVAH0801A^M%.'.[%%%%%&)S_F[1M#
 MR]`OGYMR/C`**H(53X1#?:F2!+D0O"I9(/B@1`(1(,3'WNI[(?$S/*I3)=\^
 MM_U^V`'?9.P]I12J!24*A&3XB&8%P&(S)YCK3$;(-0RDZF3%Z#&@D^:>[K,#
 M:C#TDV8G"X<QSALBDB5&I77;GZ]51<0(CHF\@283<'-(0BP@033(2@W8;@U#
 M:`_D`CD(;DKNL;O+SUJKFX+Z(3U^,H[AEOBF&+YN29M%5W=OR_KR>5=_XKCU
 MT&'`T&/\I+L%XCIG7#;G<C$`3+KX'@9(;RI%418(X9OUHP#%R/PWV0YI-C`O
 M0H<,$0\HE2*!J,E!8[B'"&F:2*:$KW[[-HQ+$I]J7U!9"D40%6108HC#5>RE
 M3HF_*!QF$HAU'[Z0X*9C33$()`I@8+^3/.78]Q/62YM8AZ3!`N#=F:*$3Z#T
 M3IA(PE0A,$&Z'E&@"?%V0]K],2X'S!@&VW9[:%UG+>IT@?.%@.*)V]4)&&%4
 MP(,@I!`8*@-82L1ME(\-3!(JR4HA4$C6%01(Q&1`112+(BL59$$$4!@R#(@K
 M!8152)((,06,9%%A"P&6,@?#4E]S/D'K]E055B1A\(?;^5;;'0N@G$._ZZLJ
 M-2UE<?V4#O\H6)*GB;A@>?F0\S`(C"`GA/$KN>*B=C%#8V$2F*K6VM:?3[<3
 M4B&L'%2%1.!:,).P#1265:W<HN"P8=)O+0E$N0+-C>3+QP?V!Y(;(\VGH.!2
 M448C[T18!JQP`,HA]SZ`ATRXSH=*&HMI;%+*LZXO/(K2';>=<<`8)`0RD#B^
 M_9;-D,XIK-7!@3JP4/R/45"[C@Z9?Q9BXF:[%HA9'K,T7W86&4X9],$[]&X<
 MZC"H9>,,[AFY%UN(Y&3-T=0L,UFC4%$F&]FM)+-=Y=<X)3TX;AQ1&[E.!@_D
 M[Z;M9.K!N'PUT>W6\M-E0K/>?Y[U0$H(CHQ?8,?[;N'V%9I$W%!]2FXD,3:H
 M&7T*,+>#+QV5<.`G)-SX]XRH;Q!-Z75&6"9"##HIALG9R]*%Q[7H;02J43C=
 M4TL)`@2.0T@SBOVLSQ6K0X.PXG!:Q]N+Q^GLS:8#XIM`M@IO0Z(6R!4@L+Y+
 M\"T7=![3Z\X3PR"B8]BA'N3<R'&Q46:4.SU:GP1'BG6V(NM7,-Z+4K4N^.9+
 M\0[&S#G#.9TZBUZE6D;,O):@Z"58N5+OHCWB^CST!<+IHF(9#/4]Y515L<R+
 M6"/SH88AY0&52%04P38R"Q$-`DTRL,9`UDM$J!-#I`JLG(,V)!$FMA!AX$71
 M8Q9Z4+TQ1'"\"@&S*Q"Y=!H(`(@Q&1X]T+A"'.P^>-/H2_ABBZ:&O,Z10#D#
 M9LV4I^03YV>7B3W8:YY/ET8S)AXQ85#)`#-@;<<,N`8"(<:H0C&$16",!2"R
 M(@1@P$&`H046"R*Q"T+&"009YY+%,S]D&3K+KGW$'`B9]OSV,`P*?=#KZC=S
 M*C*WN\2!`J82,#PU$:G7@ISEQOZALG50=$WFJH7VXLAP<G0@&O&,/.0Q%0`2
 M,1%6(G0S[RA8C%%Q,+!#$<#$PG[9NX9<TI#C5!ZX"]D5.GK`.)`-S=X!'9``
 M[F4/>)YU*15/8=LD]<D.'!'F-:#*]#3*1B!\L'MAH"R/''A9"[#T4R`AZ$..
 M;R)O.24V"7YXG-+"JTI:[@9%74`O$.]@TK2,_)2&E++3")21$@+!45@LJ5B"
 M'>U!%B,$91+"\49>76,*(5!!LMA$E0%B%NR2!@+);!%B4*0+)49/$+&A=O(L
 M0NP5&@N-64+#200I1@U!@!C%#Z0L.:GHADX%P<B`T>H)F.+M=I6608PL&!`[
 MT7)'XF7K,#/^RQ7^(7?CE[@A/$8"@H'WG4F=2Z\P'&ZX'?F&!B+<]U!-#?_$
 M-7(Q([8DM1],O$_87_I"QORA5E&A+4AUGV(&"^1M.LU,9,FS-OU8X7%":=,.
 M@GDT?M>-!+[\S0>EI-U%!7JU$CN-[-,RVU]^E)[U,PU6>20/N-[":!H()N`P
 M0(QA)%(`?K*6D1#<)2(0@A0NUU`.KN/P(TZ*/T<Z1'V`KV,&OH(=3)QGQH+/
 M'B)QC-`^"B`?8+8+#;OL)8Q#QS]$/>-T_.&J9H'>!UAL7:70#_J%@SD=L#:A
 M-H7`$/SSO2Q).N6BG5=H3&*%8(D9XMGBRC%BPX^/LD,)P,4VPG48@6##LI+)
 MV"C>P,@,DDY!P,Q'%!4T[`?3`T-,^W%$Y8@2BH'?"4TB6["V44GIG%F&@F!Q
 MO\87-33$]66*Q&)(=9&!:'5A(]M`[2)@J:/<G%W^R?-+8GAXC`3W]7[4AY1@
 M`Y/!(+-.HZ2HHGD?Y4[IJ@SUTKZ#=G&6<,V@IM"SKN]+YOH@,\!<;@8+C(&;
 M<,^RCPGB!*!R!P'5@@EH?V&ADAV]11#D5*IVJY[&&@Q!->&HH8Q/9Z?4PJ,G
 MFP($!J)'RHH33DIL#$OJ>BD!,"7Y<,@/A$3T;T:;/TA+[TQ/*8AZD-^B^M,#
 M8$83(PVXO,YRTN=#)'ZL%$*1`SZLD>L\^)9AA"$CB,!/#D'7A$NG1=,3("HI
 M(G84$(!%[/[RDN-^<M9$K.0B_?@_R/KB>'+IN5:UZ"9?=_OT\DWF8Z%\ANB>
 M\6SHY>N]V&$4%5*[?"!@0K1;=JWO8#S*P9.589IIYEYXPT6)@*]IR.1[,PZ\
 M<):AL$/\K/A:,C5-C:*5*-M;R58F!&@KB->&YLS'5LZ^D!$>O!+#OX!EXFB.
 M24M5&W\#.+`D4=)6=5F,Q)3E"]'YW.<>+Q1::6Q*AQA#(3(IW:]VZ*T[36&V
 M3M7&CN<C/-:6"<EUD-L6A7"5Q3QHO'6RTQIB+*VKV%6R!K`AF]B:ZQHY&C&[
 M.0QK=/L56\4P[;9I!X&[&H:Y=@."LV9W7KPY)/EPV[+U]/H_AIYY]F7K.)PV
 MEA)JD14$1815$9!$1@(P`48@(AD'3K17Q_0YX[\.S1Y1;RKMU]5(X?),MCB7
 M[R1JL^,VN9LY7!ZL-GV3:IU](V0\^B0Z$AJD`LG6T)1$_1`QT]Y/JV`_L#X^
 M>IP&6_I2L6`7=1^JA44:EGK3>%&Y^^?0!:(>Q*&YX&VP&1.0QR5C>C,-S^X"
 M6/4U!HH@K!SXR39L6@@K6!W?':4;"&*=;1J7;DN25<MUYVL7I]C.1//KK1,4
 M<E01E]KWW=BU`P>"4)&0Y,51$O`[TUO%&5GGZ<.4J7M-$IX,8.+_/"VKH%EW
 M!16Z)<EI8[&0#F6(A(]8CTNX>^*3MA$(3A9<G@<Z#-,A.A"SA!9I`/0E'Y\Q
 M6I"=`ND$!(#+0]SQ04"DG)T+/`R^E,-]L`Y*4_?@D]D2K!U3=%[4Z"B-&A$8
 MCI0LT;36@ZJ+7!5FC:UN9^&,AD8B><7^X0.J`/6'U(0(-,]C!DP&0(<$BC[>
 M<,01D.U7D`SW3?Q&S!Q)G>S(;,DMBD1]A300)??#0LWC*9)&\6\1<)'A>PI+
 M?&Y$^#0?AEE-)!(*/",&P/2(RR%X'<C]-/,L+Z"A8H2HNP&&<6$]0,-(!:6\
 MP-=Q0D@^BE$MY!1<@B^N!Y`'L*!S'W`"=HGE!.4^I#$B0QW-T-AHTB!VL-=8
 M6C4@P@/6!XR)ZOI_B&TYH[>_6W$/`#;OOLA:>F]/KC>#K:C)CYF*;)(80`I6
 M@<H5Z($A0YW3HU0B_>!ZPZAI8@CRE5%:MOB)L-)40L);Q8C7"EJ$6TLY[-AH
 M.A#JV(%^YRB.^&@@4PR65I;X<9-\5@QO.!MA79E$4U+F42F3<Z;#<%45B9#=
 M7!R3-F:BP1VG9SF*"I52Q&]QEIUS.39!!BZ/VE7B0K"RHU_`:E!G08)NVC4H
 MR'4S&.6"HC"\/!,!C%!U3>B0Y0AQ=[1ZEE$.&/!<DM%FK!EE:ASH\T![='+#
 MF30@L@JU(M;S%^/L/\C7`<#+#[(TH6'=9LO45=H^MH*L4%/N]W?9Y#YO)&W=
 MHO(=3:)F1!W@6"\"*GS#`6ZDS@I%U]OLS#JU$:'9F$XM1#0V*?>8C:87XUDW
 MK07+#0%])N$NTJ2<V`?43[!F&/(<A,.[ETZ8<*3YEM@EHRO&R01+O,S?,#(>
 M\RRA7L.X_J2&]%AN&GR0H$K3B1\T#GK-C$HL:-'&'8KZTUQ:1/W8%<PP?JAG
 M!,?]P^DBU#V#:E+2[Z'C0FIX*;$%Z2(W/6=!Q+6"23SE8*L,"6D\Y5U%-55U
 M*$H[QL:D(E]B+7N,J$*+.[MI#*(GT:D@()IK$JCVNJF<"YZFL8:DH'14A-IP
 MFU+BQM:C`D53,*071%(2$(DA)BTBT,$G(B&:$4+AY"Q%W!8,@1-Y$!<5'S0#
 M>&WO0P=1^@KUX&Z,1`@]12NI%/<FX$L<N2V5_C$`HP6PEMH+1X^T`YR<L#F0
 M6"A81NBERX%%.B3\!3"(=05LC(6)#X/C7>YX`=AAU`[690*P9*T&`Q5%"`P@
 MPC$D7B!MN!<ODR3:FKF8":#K+P<$^/*JJJJJOXPPD`IHZ%H/XQS'[O=1GG2,
 M!'P/MA5A5&`2!RW(3##67,F:$1Q,[K3CJH=]M$G64YY>%8O'3+XJ("+$!I`J
 M80G&!\$T?B2#!H5-[;=2KS\[U+\?N1SU1?F]+\[%I:6T,""4"SFE"4O+^S6G
 MQI3#GV&W1_)-!-A:;[:JV.#"H@%1RS0]K]QMB2I9[*N"U.WJK4R>N""H[),F
 M9(YAU@^KK/A(;B&6Y:^PJ3)RBU*7<-`HH[C-EFR'$,"$&['W:W3)4?\ARTNO
 M-2-"<A$Z\E4LD43<KS2.M'J<B&R<.?`7"H*4^=[LV(H(((4,$-S>YR*4)-1]
 M^*06365I)@3"-XDTD?4UI*$A%I%AW4\<BPKS/(SC3O-Z*;WPZUSQG7>8H@J,
 M'LM'I!*'//&NW7;#C>^V!3>HMO--(PJ&BH70DG;*\).A9R]"RZ4\C@[WKHN6
 M_!1M"C<)BY#:(%"*.YL/EX8BA>$L$I$GB.<9S#8=Z@[D7,)J,FA,:N[4X)#)
 MVKT078W6>4;2YK9R#V+?L_IBN%+JDLS4$A,(&!",.Q/99ANX6;E9.-6.5H%#
 MD\43"*E#I0;FQ/9N#3+`6%+UE!`E.U3=S:K9V>QL2J%=V%UA,F.*`KX2ND\?
 ML5-.6YTU5R!T"Z&6C5@FU(R62WOH+O0O..-9E;8:VY=\UO$:L4%V:6BK$L+,
 M!."2S;C(!)5>MJ5;P<FSFKL/;6\-->E*O&FELX45!7CZ\Y;ZM;X.]J<.FSP0
 MST_(0/:A/&,.Y5!!,S^6!07C;<&OD"=IU*"VT?PH0?JL5M6-7>W<%,Q0D[NY
 MLK\+%F5_"TS:O*PFT7>>&^._N/)T+W0V8?I$[7SFYRR2*8&&*3%C5LL[(;.\
 M[B<4.GZ4-T@TGI<A#$4639XR=[("@,R3V6\O'T7Z>YN_W-\?6:&3DOSD3#$S
 MEMIW'99QF-%)ZR<DJG!>L^\HNB'4"OMFP%3JO+`!E7A6%&-TO?`1QM,2;:_5
 M:JD$14B6!P7FQ$549V74N,151%1>K8HI;<+*86A2Y[;)6[_V:N_"H2]%,-`S
 M9\<%'4U,&D(@<H'I`3QQ1W7Y6<AA8*(=P8A1UP=Z[((CK`-.^N,H$C!7'/<2
 MI.R:S\[@TBDZW,^0KEFC<@'%!.(,119,/KF6N,(]H9"`?.@'A,X=.RH!JAL;
 M2A_)N7.RZ@<]77;MF1U57F)]KNPB<<J5QDEE3H!X8#RB>$LL2(=Q`01^)&&!
 M$/,OI0.]((2ME=CND-2D+6=Z$1M`R[@M5"(<&/FH[.[EF^F6F38[E0N6KN]F
 MYNX+%/RRY3)4N\ZW9M&9TEC(B/1C35,*9\FF$[V$/X$%L1X&)&JGH.F(E"<@
 MG9'+:A>TW5(:=7Z0/U!OR*D*5:]ZD10V(="OCPG.%P-R:I/K$KJBYA<G'YK;
 M4M>9Z;DAG,7L(^'QD.88]$G@:>L#H*BS<;$U7:)($UB,LA\+F`041)$6,&J)
 M1$M%LH52T*58J#`MB%D)/?'RL(>O3CD2$;H9(]00R`:(!%@8:I56$87'"'`I
 M@8AO+&Z(\2E(($^:4$@D)M"'45$01^RT!9.B>Y(!-8@-1$]H&XQ3J3LH[/9D
 M6#UFRM\D(P1ZK??X`630HD_=%R2S>#V&8>JA)HX8@T.\E/H]55IZ"S764++"
 MFER30IH6DH3%0VSEEK`2&*#$*N1E7(A_:;%+T=7-3BF2?%$H3,.=I59PJ;*I
 MN\HRV*)V&9->G!P/#Y0X5T%2NLL5!<3"9DB-9+,/;::.#-Z7UI"J<B,;OWI5
 M^^I#<,R`0#"!Z-]3F:Y@F>(@@B=;H-)J$H^I)316`4R,J9$,0&EJJT":"A29
 M$]DOBTJ=G37LV'@<VYW&(5%\FBT2@I6VB_<2%;"D8<#@0^QLT.M&CEK6LZH$
 M6>,5+2\?<#+'?:53X7PC5I2"_2<^""K#F,"D@,!_WLEB26Q(/F7U^[&R?XM0
 MD]0^`#PF1%2M`N)IM*81VF\^GC!>]`JCTV<243]G^`:UY)OP$RA[(YLV?7FO
 M.L;:XPUJ^$.P;)NN3*P6*'X01UZF).UDGY#/W`>'?FDWO4,AJX:-(,FV3A$9
 M*&]R8%UB0-[,P!<&"G*8D+!`G$PA<Y;>7-QPF[@_6Y&.RM^EWH7BYT4H@[X<
 M=&RU8Y*+7:C,,Q?!WHVE:BI)5A#T>:##HH4*33$&EBT&N=C7%2YEJI(1!%\\
 MM9H19AQ"NT.$:UT89,B23(4H<]"PS$#7S:Z3W#-:9*U-(H$T3.548RY!E&<`
 MEJ/6\PQ$4Q8RVPTDZ#CFCNB2=-%0=9E@0)"9[.]NFCM5!1%<BR:MU,L0%6.9
 MJ:WG8QMC>AL(YL<@L,BNU#?4IF=-[Z%=33,DHV:;8V,I#5'RXUW)6!!4:%CH
 M&X^A,*$05='[YY::)F:EABT7X@I5:%[%7IO9&+W-?YP;Z],SU#E2,!8JT%GY
 M,?:]=ZROLX2%Q9#YO<>KJXHI5G)@?!P1*&(4:"`C&]DOES8/EZ].$G#S\])X
 M?/<:IW11.AG5S!+-,YCG(\_ADHPN'K6J3.1:605#NS]OVBHJGW\5S*^VE48Z
 MMX)E9;:'\RV<O%E%Z<X;QC,MFC2EX%-0DJ+J:#P.Z^Q+PW%`6;\1MB<49O9(
 MZ@*6-_"#<:Q9D,HP:DL$V.;_6(G+?VYEC4[';C?*TIALK?X9#CB(;%@#%(!&
 M2)2GFX9VL,3=Z[F#Y#=S;X]N*KE:NG=G&8E#!@#TH',#"+?S-C'&)HU\N&&'
 MQ9CRWZ[Z7#BHPL8C`/.K)T],^3$UJ%B)>#TXK49@--#DA0%M_2G&Z!UIJOL#
 M;27."YHG4$(R#$LNO((HY%E!R/ESL"@YD2Y@]0,T#>I%(,3>C"4)G`-3P!9#
 M=**BMS$`W.NFMM4IB60^Q9$*$.W-M(;U&7!OD:.H5.;QV\AQ$YIN98PYYS8=
 M>"'&@62MET!MD4W6!7J3;G?O@N:,(1?5.R-`S8`60L5ZVL/$N-_:;4]Q1PM(
 M)V1+WO9DJ'`^;S<&Y<B<4#9J\2C<<(=J<N,*&C#CK1T#`$>^@@NJ/E]NK)-P
 MBB(QDJ!:2I5W8(LDLKQFJ*(@LD1`(H*=80+`80\Z!(`IU<Z0$[AW#"A<&('<
 M$38;,--MC`GVM)RM0]9$._*CKU:'\;"#QXU9(I#F6?F%H.J``/"/0;P;H7"Z
 M8UIUK6@5]&=I$S%1)-,.Q7<<'30K'C%M)()*K:OD>/WZ!I[>F=,*5$O@W`3!
 M7:YUVPJ7R$4I.:VWD=OP`O6+TT5I;1%P^U^8^,B*"^C#UG<G=$Y]5R%C<0N<
 M[]IA8LH7,6*0E4!0P$8(SO&M&%CHRPP219Z)O-&RE)/;G&=V88X&][CHTG>U
 MQ(S)\/F*55Z,G50.KNI;H1!WO(,AU+J:[O/WW[-K#:9?4X12C:=!SWTERBE"
 M1$TSDS2JHVZE/#>ZF!/+'$;6=JV.@Z6FW-T2@.X$@9\1DD(L=E"%4C)$815D
 M^!]Q.G9V%RMT,F``QBF0E$`S0JRHU$+*,#*]`C!^Y.)<D`R+B'J=\XPKU/*X
 M:?9EWO?HS,'Q/0O19AGP\@@<-XW(Y#V'G:%GM&1'UMFQ&9$+(&4Z5,Y8UX;&
 MQPI)N@B-T.3+\''3"9C`WLV-?54)G;:2^&24_)SZ6619B>8>$A>P0N_9('6\
 MSH`KJWA9!2DV:ZYBO4Z[)F>0VP]1UD8R2$.V,@$*:&,0ME4!!E8$/9Q^0G:D
 M<L+\_JJG0.9*-2'SN9=2H&^BT)AA@:P>98'<GRDX!;W_(HP?%`65$VC0,KFD
 ML0B,!]/^!_1<N5\B(GB4E2DL@8NCB9)=F\.GXIY5"P[Y`XGS34-ZQ#8D`Y@3
 MA;QL(>3!X2!PL$#\PH.\@/GIGI555S>>@;;?IJJISL?(:EWA)`6]"Q!]I4+(
 M3%JCU=/[X@43[7(F]"67(6Y$]N@B8<*XN]C!B9^W"*3J?IDZQ/T11A0]JG9]
 M#'!ZSND@O\[%7+P.'0TI;X"[(A<OSB3$_\0.T[?W[%O=7@N3+L4JRGR[(3M`
 M_D-QXV*G17:7IV0T'@&!:3(!#B8-.YZPI7")`B'6I!A!D5S0+&@3O@4W1S(<
 M/$890SZJ04A]L#%&`=%79]ZC8&L>+Y[Z]U\&,(0.&!7@?9@//.C0Z@:#P9F)
 M/)D#@[T/S=N)41B:*SOHULP8)Z*?OX%S<.NA^PLT+H_9T*F;),.B=5C"=_GZ
 M2S,?%/@A=[Q]R>\)"24M0A(I/)*1[H::&Z%A.3TQF:CJ?C^B28NORFG;-Q76
 MA`_2:9=GEOJ\CL8GMX+*0/T,AHG`SLZA:,_$<FQ#!-F`EOX*TT.=;[TQUTWQ
 MJIM^9LX./C<?)*UTO-[-E.-4"I&(E#0`&@'U3T*2QM-1,+9ED-L62\9G=&XA
 M98#Z6K''87!R>K%UHO$UF,5%MV]26'2^N!D`_`/<(HM?*5?J)9IB0P00@IE@
 M)R0)4DR300GQM`6N!NB1%:GRM8@GLHJ2$MRM%B2(=7':@WU%Q$;V<84DWZDF
 M`44)G76C21DOPLN0=OAG9A2FI**N26I@4R+&,70-0S*91';>KZP<[YTDYX,`
 M\:9*`79KB8+LL!?V?-RTPLCUAX5V#Q],A*&'005!CUL*C;"V@6""K-1"4(*B
 M(,42,DU0C>\NX0`SWWXRSK`OM$`09\\9L<NL`V.<.%@^7PAT:U`Q#22,!+[L
 M,$1!AJ,/%]+9"ZOY-I8.T?SV;VJI")4&X/N9[IPJ4J+1"V6)[3.^`N:RU]D/
 MB/7"=0/1>LHM9V6.RJGY(!OA8[8I[.ROF@K@)C`HAZF?#N\XB42)]%A=S:NM
 M&H`:8*"B55+*P)8*E@-Z0\PY"T@&D;CO$ZBGH.>&N*?.H%H)%[!CSA[&.D/L
 M:1-Q6<A]\/WX$U'6`<)G&!T,/#.$5SHVIDD2-&*9D")9]64]*+VB/7S#34&%
 M;+$BZ7MAI,/]&UD,+EB3^P_@\5Q/VQ,H&(D&9])TA(+K@Y1`W=+I*H*&&BF!
 M@IJY74P>D\3'QB$FIGG\7W_1PO]>?AN_S/O?R8>KSH?.[/8S:Y"@6;@$$$$*
 MX><[=CA.SB:SAZEA[T-]638&5'IH3DRCSTX#7X+T3@=Y5/QRA33US$*'5<#2
 MJ8&HV),$^1_E+80;G[]'^<VX8SR9@\"[`WO4Z=/-@SU/-VZ^0Z>.\-O;P]^F
 M=K,OU0T:NE;!P[-@.RX?4D6EQ)F/0,./T81I80=I^3CJ'L(AD#C4&E7>#M-J
 M*<`]YL^VU$D540^\E9$5@M\:8$.Q!`.EXT)#],O_U*50YQ%)$^P6!"$8)*E%
 M`(=41BK%$8!D)(?Y$W#VC"&B`J*LGDI^EP2%H%]O\A[OB'ZP@'TWW:YJIN!@
 M.^*2-R&=W[#XTM09^A)#E.*$&%598A"<D<4Y=.2<(B4_0B)_L%);__%W)%.%
 &"0YCX?<@
 `
 end
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

	[deleted duplicate copy of ps-patch - gad]

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 9 Jun 2004 20:34:10 -0400

 Thank you for the newer patches which have all the missing
 pieces and are based on the newer source.  I hope to look
 into all these changes as time permits.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 11 Jun 2004 15:57:42 -0400

 I do not have time to look over the entire set of updates right now,
 so let me just comment on the kernel-related updates.  That update
 is only 500 lines, so it is easier to do a quick review of.
 
 First off, the update indicates that it is based on freebsd-current
 as of June 8th, but diff is from an earlier snapshot of the system.
 If you look at the patch, for instance, it does a diff against:
         -r1.202 of src/sys/kern/kern_proc.c
 and    -r1.128 of src/sys/sys/sysctl.h
 
 (among other files).  However, kern_proc.c is presently at
 revision 1.205, and sysctl.h is at version 1.129.  Those extra
 revisions are pretty significant in this case, as they include
 some of the changes from the patches that were originally sent in
 with this PR.  So, some of the lines in your latest "up-to-date"
 patch are in fact not needed at all, because they have already
 been committed and this PR was referenced in their commit message.
 
 The earlier patches did not include all of the features that are
 in the latest patch, and I will look into installing a few more of
 those features.  After doing that, I might ask you to recreate the
 pieces that I did not get to.
 
 The kernel-related patch also includes an update for conf/options.
 I believe that file simply defines compile-time options for kernels
 and kernel modules, and there is (IMO) no need for a compile-time
 option for any these new features.  We would only need a compile-
 time options if some new feature caused a significant problem for
 ome class of freebsd users, such that they need an option to turn
 it off.  For these changes, I see no reason to be concerned about
 adverse effects.  So, if I do ask you to redo these, you can
 completely skip any updates to conf/options.
 
 Since we will not have updates to conf/options, we also will not
 need any updates to lib/libkvm/Makefile.
 
 At this point I should include one important disclaimer.  I am not
 a "kernel-level" programmer, and I do not really wish to become one.
 FreeBSD already has plenty of expert kernel-level programmers, and
 my own personal opinion is that I will not contribute much to what
 they already know.  So, I may shy away from some of your updates
 for no other reason that I do not have much experience in certain
 areas, and I do not want to take the time to learn those areas when
 there are so many other places where I can make a much larger
 contribution...  [I may branch out into some file-system issues, but
 I have no plans for anything else wrt the kernel]
 
 Having said that, I'll now say that I don't understand what your
 updates to libkvm are about.  That does not mean I think they are
 wrong, it just means that I have never looked at that, and (at the
 moment) I have no idea of those updates are right or wrong.  I
 might look at them later, or I might leave them for someone else
 to look at.  The updates I committed to kern_proc.c and sysctl.h
 do seem to be working quite fine for /bin/ps, so I do not know
 why these updates to libkvm are needed.  Are these for handling
 -N/-M requests?
 
 Moving on to the update for src/sys/sys/user.h, the one thing I
 want to do is come up with a better and more-reliable manner of
 defining ki_spare.  Right now your update uses:
 
 	long	ki_spare[16+(sizeof(long)!=sizeof(int))*2];
 
 and I am reasonably certain that if I were to commit that, then
 Bruce Evans would tell me all the cases where that calculation
 might not work.  He will refer to hardware architectures that
 FreeBSD does not presently run on, but which the C standard
 supports.  I am not *that* much of an expert on the nuances of C,
 so I suspect Bruce will consider situations that I will never
 think of.  Also, that calculation is explicitly tied to the
 variables that "we know" have been added since ki_spare was
 originally defined as [22] (which is what the present code has).
 I personally would prefer to set up something which will
 continue to calculate the right answer whenever more new fields
 are added.  I'm pretty sure I have done this in the past with
 some other program that I worked on, I just want to remember
 the specifics of how I did it...
 
 [at one point you mentioned something about "how NetBSD/OpenBSD
 do it", and I intend to check out what (if anything) they do for
 their version of this struct...]
 
 Once I do have a better way to define that ki_spare array, I do
 want to add some of the newer fields.  I will probably ask Bruce
 about some other issues wrt alignments before I do that, but my
 general intent is to commit your changes.
 
 One exception to that is, I think, is what you are doing with
 the field for ki_childtime.  We should not blindly redefine
 what that field is.  There may be compiled-programs which refer
 to that field and expect it to have the present meaning.  There
 is no urgent reason to break that.  I do agree that it seems to
 be a waste to return ki_childtime, when we are also going to
 return ki_childstime and ki_childutime as separate fields, but I
 would just as soon do that for the time being.
 
 Also, when you define EMULLEN, you should have defined it before
 the struct (with the other #define's like COMMLEN), and not in
 the middle of the struct.
 
 Please be a little patient with this whole process.  This message
 took me two hours to write (as I cross-checked things), and I
 haven't even *done* anything yet!   :-)
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 11 Jun 2004 17:44:12 -0400

 Let me also say that I am just writing up issues as I notice them.
 I may add more comments as I look closer at the updates!
 
 One more minor nit.  The update to user.h defines:
 
 +	char	ki_emul[EMULLEN+1];	/* command name */
 
 but that is not a "command name".  (what *is* it?  An identifier
 for things like linux emulation mode?)
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 12 Jun 2004 02:49:47 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > I do not have time to look over the entire set of updates right now,
 > so let me just comment on the kernel-related updates.  That update
 > is only 500 lines, so it is easier to do a quick review of.
 
 that's a beginning :)
 
 > First off, the update indicates that it is based on freebsd-current
 > as of June 8th, but diff is from an earlier snapshot of the system.
 > If you look at the patch, for instance, it does a diff against:
 >         -r1.202 of src/sys/kern/kern_proc.c
 > and    -r1.128 of src/sys/sys/sysctl.h
 >
 > (among other files).  However, kern_proc.c is presently at
 > revision 1.205, and sysctl.h is at version 1.129.  Those extra
 > revisions are pretty significant in this case, as they include
 > some of the changes from the patches that were originally sent in
 > with this PR.  So, some of the lines in your latest "up-to-date"
 > patch are in fact not needed at all, because they have already
 > been committed and this PR was referenced in their commit message.
 >
 > The earlier patches did not include all of the features that are
 > in the latest patch, and I will look into installing a few more of
 > those features.  After doing that, I might ask you to recreate the
 > pieces that I did not get to.
 >
 > The kernel-related patch also includes an update for conf/options.
 > I believe that file simply defines compile-time options for kernels
 > and kernel modules, and there is (IMO) no need for a compile-time
 > option for any these new features.  We would only need a compile-
 > time options if some new feature caused a significant problem for
 > ome class of freebsd users, such that they need an option to turn
 > it off.  For these changes, I see no reason to be concerned about
 > adverse effects.  So, if I do ask you to redo these, you can
 > completely skip any updates to conf/options.
 
 the compile time options are essentially for testing purpose, there
 are not really needed except, maybe, PROC_NOSYSTEM for the moment.
 
 > Since we will not have updates to conf/options, we also will not
 > need any updates to lib/libkvm/Makefile.
 
 nor the ones which are kernel related in bin/ps/Makefile.
 
 > At this point I should include one important disclaimer.  I am not
 > a "kernel-level" programmer, and I do not really wish to become one.
 > FreeBSD already has plenty of expert kernel-level programmers, and
 > my own personal opinion is that I will not contribute much to what
 > they already know.  So, I may shy away from some of your updates
 > for no other reason that I do not have much experience in certain
 > areas, and I do not want to take the time to learn those areas when
 > there are so many other places where I can make a much larger
 > contribution...  [I may branch out into some file-system issues, but
 > I have no plans for anything else wrt the kernel]
 
 I'm using the kernel patch for more than a month right now, and I
 have resolved the kernel issue I introduced at first... don't
 remember what there where ? (probably something like null pointers)
 
 > Having said that, I'll now say that I don't understand what your
 > updates to libkvm are about.  That does not mean I think they are
 > wrong, it just means that I have never looked at that, and (at the
 > moment) I have no idea of those updates are right or wrong.  I
 > might look at them later, or I might leave them for someone else
 > to look at.  The updates I committed to kern_proc.c and sysctl.h
 > do seem to be working quite fine for /bin/ps, so I do not know
 > why these updates to libkvm are needed.  Are these for handling
 > -N/-M requests?
 
 well, it looks that kvm_proclist() is a fallback method. however, it
 seems the fallback methds cannot be called regarding the actual code
 (i.e. ISALIVE() cannot be equal to 0 since kd->vmfd cannot be less
 than or equal to -1 if memf if different from /dev/null, and if memf
 equals to /dev/null) !
 
 to test the fallback method, you have to modify kvm_getprocs() such as :
 
     if (ISALIVE(kd)) -> if (ISALIVE(kd) && 0)
 
 this show me that the emul patch is wrong...
 
 "if (sysent.sv_name[0] != 0)" must be "if (svname[0] != 0)"
 
 also, ki_tdev is not well handled at all because of dev_t vs. udev_t.
 I'll send you a patch separatly including the above fix (svname).
 
 > Moving on to the update for src/sys/sys/user.h, the one thing I
 > want to do is come up with a better and more-reliable manner of
 > defining ki_spare.  Right now your update uses:
 >
 > long ki_spare[16+(sizeof(long)!=sizeof(int))*2];
 >
 > and I am reasonably certain that if I were to commit that, then
 > Bruce Evans would tell me all the cases where that calculation
 > might not work.  He will refer to hardware architectures that
 > FreeBSD does not presently run on, but which the C standard
 > supports.  I am not *that* much of an expert on the nuances of C,
 > so I suspect Bruce will consider situations that I will never
 > think of.  Also, that calculation is explicitly tied to the
 > variables that "we know" have been added since ki_spare was
 > originally defined as [22] (which is what the present code has).
 > I personally would prefer to set up something which will
 > continue to calculate the right answer whenever more new fields
 > are added.  I'm pretty sure I have done this in the past with
 > some other program that I worked on, I just want to remember
 > the specifics of how I did it...
 
 ok, replace the above expression w/ :
 
 #if     defined(__i386__) || defined(__arm__)
         int     ki_align[2];            /* per arch timeval alignment */
 #endif
         long    ki_spare[18];           /* spare constants */
 
 PS : I don't have access to a powerpc, so, the above expressions
 may be not correct on this architecture.
 
 > [at one point you mentioned something about "how NetBSD/OpenBSD
 > do it", and I intend to check out what (if anything) they do for
 > their version of this struct...]
 
 in fact, there is no version info in the struct itself, but a new
 syscall (kvm_getprocs2) and a new sysctl (KERN_PROC2) which both
 have a new argument which is the size of struct kinfo_proc to return.
 so, they always add new fields to the end, and only the updated
 programs may get the new fields. not up-to-date programs don't
 have access to the new fields since the returned struct kinfo_proc
 is truncated. IMHO, this would have to be implemented when the current
 struct kinfo_proc will be filled and too small to contains any newer
 fields.
 
 some pointers are :
 
 how to call kvm_getprocs2()
 http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/ps/ps.c?rev=1.54&content-type=text/x-cvsweb-markup
 
 struct kinfo_proc2
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sysctl.h?rev=1.116.2.8&content-type=text/x-cvsweb-markup
 
 sysctl_doeproc() / fill_kproc2()
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/init_sysctl.c?rev=1.30&content-type=text/x-cvsweb-markup
 
 kvm_getprocs2()
 http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libkvm/kvm_proc.c?rev=1.58&content-type=text/x-cvsweb-markup
 
 are these explanations clear ?
 
 > Once I do have a better way to define that ki_spare array, I do
 > want to add some of the newer fields.  I will probably ask Bruce
 > about some other issues wrt alignments before I do that, but my
 > general intent is to commit your changes.
 
 thanks :)
 
 > One exception to that is, I think, is what you are doing with
 > the field for ki_childtime.  We should not blindly redefine
 > what that field is.  There may be compiled-programs which refer
 > to that field and expect it to have the present meaning.  There
 > is no urgent reason to break that.  I do agree that it seems to
 > be a waste to return ki_childtime, when we are also going to
 > return ki_childstime and ki_childutime as separate fields, but I
 > would just as soon do that for the time being.
 
 I suspect that the alignment problem goes off if both ki_childstime
 and ki_childutime are returned in addition to ki_childtime :)
 
 just tested, it works, so :
 
 struct  timeval ki_childutime;  /* user time used by process children */
 long ki_spare[16+(sizeof(long)!=sizeof(int))*2];
 
 or
 
 struct  timeval ki_childutime;  /* user time used by process children */
 #if     defined(__i386__) || defined(__arm__)
         int     ki_align[2];            /* per arch timeval alignment */
 #endif
         long    ki_spare[18];           /* spare constants */
 
 may be replaced by :
 
         struct  timeval ki_childstime;  /* system time used by process children
 */
         struct  timeval ki_childutime;  /* user time used by process children */
         long    ki_spare[16];           /* spare constants */
 
 > Also, when you define EMULLEN, you should have defined it before
 > the struct (with the other #define's like COMMLEN), and not in
 > the middle of the struct.
 
 ah, yes, not seen the above defined :(
 
 > Please be a little patient with this whole process.  This message
 > took me two hours to write (as I cross-checked things), and I
 > haven't even *done* anything yet!   :-)
 
 I also take some time to answer this one :P
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 12 Jun 2004 03:56:04 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Let me also say that I am just writing up issues as I notice them.
 > I may add more comments as I look closer at the updates!
 > 
 > One more minor nit.  The update to user.h defines:
 > 
 > + char ki_emul[EMULLEN+1]; /* command name */
 > 
 > but that is not a "command name".  (what *is* it?  An identifier
 > for things like linux emulation mode?)
 
 
 you are right, I'll fix that right now (emulation name).
 
 # /compat/linux/bin/bash
 # suspend
 [1] + Stopped (signal)     /compat/linux/bin/bash
 # ps -O emul
   PID EMUL           TTY                TIME COMMAND
 20628 FreeBSD ELF32  ttyp0          00:00:00 psx
 85422 Linux ELF      ttyp1          00:00:00 bash
 ...
 
 for instance, the real max len would be 13 (as I remember me).
 maybe some spare should be kept here, such as 15 or even 19 ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 12 Jun 2004 03:57:00 +0200

 "Cyrille Lefevre" <cyrille.lefevre@laposte.net> wrote:
 > I suspect that the alignment problem goes off if both ki_childstime
 > and ki_childutime are returned in addition to ki_childtime :)
 >
 > just tested, it works, so :
 >
 > struct  timeval ki_childutime;  /* user time used by process children */
 > long ki_spare[16+(sizeof(long)!=sizeof(int))*2];
 >
 > or
 >
 > struct  timeval ki_childutime;  /* user time used by process children */
 > #if     defined(__i386__) || defined(__arm__)
 >         int     ki_align[2];            /* per arch timeval alignment */
 > #endif
 >         long    ki_spare[18];           /* spare constants */
 >
 > may be replaced by :
 >
 >         struct  timeval ki_childstime;  /* system time used by process
 children
 > */
 >         struct  timeval ki_childutime;  /* user time used by process children
 */
 >         long    ki_spare[16];           /* spare constants */
 
 
 this is totally wrong, I edited a user.h and compile w/ another...
 so, adding second timeval struct doesn't solve the problem.
 as seen in sys/stat.h, it seems not to be a problem to pad a
 struct w/ some bizare incantations such as the one I propose :)
 the final answer would be :
 
         long    ki_align[(sizeof(long)!=sizeof(int))*2]; /* auto-alignment */
         long    ki_spare[14];           /* spare constants */
 
 which is almost the same as the initial submition but more clean.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: freebsd gnats <freebsd-gnats-submit@freebsd.org>,
	Garance A Drosehn <gad@freebsd.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 12 Jun 2004 04:41:46 +0200 (CEST)

 kernel patch updated as requested :
 
 sys/kern/kern_proc.c :
 
 ki_childtime left as before (except the use of timeradd)
 
 KERN_PROC_RGID moved to match the order of other OSes (NetBSD/OpenBSD).
 KERN_PROC_SESSION sysctl renamed from session to sid to match -head.
 
 lib/libkvm/kvm_proc.c :
 
 sys/sysent.h was missing !
 sysent.sv_name -> svname fix
 
 ki_childtime left as before (except the use of timeradd)
 ki_tdev was not filled the right way -- fixed.
 (dev2udev() taken from sys/kern/kern_conf.c)
 
 sys/sys/sysctl.h :
 
 KERN_PROC_RGID and KERN_PROC_GID swapped to match -head.
 
 sys/sys/user.h :
 
 #if __i386__ fixed
 EMULLEN moved
 ki_childtime left as before
 ki_emul comment fixed
 ki_childstime added
 ki_align added (see a comment in sys/stat.h for alignment details,
 		PS : a bitfield doesn't seem to work here !)
 ki_spare shortened
 
 src/sys/sys/conf.h :
 
 #if _WANT_CDEV added
 
 sys/conf/options and lib/libkvm/Makefile :
 
 untouched
 
 begin 644 kern.patch.bz2
 M0EIH.3%!6293613K34\`#\G?@'HP?_________Z_____8!A_>/11#Q>=]-]]
 M]][7O$^UI[7CW'=?=;'S?*I]V3X^&DJ*::]]KMK046Q;/KZ`'%KW8!&L/35)
 M.@&\-`A-*>$4WI/1&GDIZ:F@]-&IHQ#3)ID#3)H`-``&FB"8$$32>C2GJ:>I
 M^HF]4/TFH&0T-#0`````)301"8H4_4TF:F::&34PF@TT&AH:!D-&@`!ZF@2:
 M4A"8IAJ:I^1H"C>E/%&GI#1IZ)IIZ:0'ZH;4>H>HT``BDDT9)I@DR/!)LIY(
 MT`T]0`T/4`:80``]0!$D0$`F0T"F&D3TFH/1&GJ-&F@::,U/2&@T&F"=Z\HN
 M2)H`1D5A!(IRC2A`@`J8:P2``/`7GH4J0H(E2@JH6E$5!EHVQEL++:*%B*%4
 M8B+:4MJL56VT6@T:4J..B`@'3P(8A0"?K$(.%=7AXIZM"ZG;.^=S9[O\]K"!
 MVK2HM06(@-X\8F*CA&U7$M+6*1@PKZ_1Q>M^+=\/Y!]/Q[C:[FMHVHQ-]HB0
 MPU+;(>H^+O99$[.]9Z+W#'?3F36\%$*`$(1/49H/M^L0_.WSRQ-?L;T4K6FR
 MK>#:=NVXDFC]-XOJL(:C4CJ<31F3")AL"_OT\2QLHYYP,U94@HL%`7Y);@KK
 MI@VH36)G:3*8!"VBE5"F=P9#EBD0A"!+OGA_UO.:>!SH-\'G%MX"%BA>]S\I
 MH5"SQBI%Z*V98%;+O&#V6Y0YX-*B:R=3@JA2F'5(I2/,0HATDBIOYM&*W"K7
 M4XP.*]BR92D-374V)*Q@<]RBI/C=HEV^]-&KW6KR)$B=%;^&SCWIQ)M:,[W+
 M"Q0*"'$1YE#OO\L0VG]//72*\ZJQ9L3E8[=SWA@W2HVC<-PU@7XN%!RE-+(J
 M/C436B,P9Z2[@:N$GIOBD`<9`4XPYX+4:K.S>HXD:[.:M2%H6Q\\!V)B]:%;
 M6Z".+E@8Z-!W>GGV5M3<J8#:($,E*4/#Z0PONG#B;`<#(.-D!O@,=%!;G'FY
 M%3=JMIP:F*\[#B?ES6=,$W4A+TJ!7KTX,.2Q+1V(2"1Q2)!H!7%(/K#8>)=.
 M'EYGKF1EC)RFFUAHVN;C6/7#Q+=N,9\T],5XKRFFF]"[6,R2R<S2M(J:!5#<
 MANA"%\:(=20S"2'#X8"+!$08@HXI5EGZ.[L/=M^.I*.#`M_M?LK_CPO1:PU<
 MD@?/@$G(B(2Z<>^)4(!(]ZS9"$IY54.WYK]=9JADLVD"%X%T*"7J)%8P"4A'
 MA;X_-X_'9WNX<#IWF_[[*WL3?Z>;]ICWRLQ\K*P@-CF)CEAB[KNLP.SR>_P/
 MG<#XROB>:<F"(9^.([:+TX=S!7F;NZO2GI^%F`U\C-I7N27(O0CK-"[<T(UQ
 MAV5\$VK&'+.&:(RA(G1DVK=$B(6;29''G)Y=:?7A$&$9/&A.:4.#S"Q2F,JD
 MW=#RVM?0V6PV&[HRW$_4.KO[>/KQ76L5-IA5UWM!>78PJFBK;9L@!",]CS`1
 MEDMTZXH-P@.-5QI4BO8(1I*+Y6L7P7IE5_7AD7Z=F[M[>S$T^JE:4(G#</"%
 M;($@@1XYNVP8Y:CIL\7\]@J-T8L33N5#@<NGJ#<TA4ICD1K9:98/MU<$2^/S
 MV7#/NW$G!R>JX<F>\>&H')ZYD.R@\4XXJJD'>5/+?5F+<@'5Y.OAC0@9\W5M
 MSZ[LS8;\)`_+59G8DHMQ^B]W=G'=!EJ?/Q[;GG#.:X;S&=:,<30#*LNIO.P_
 M%-,TQE&.7.MZ?P+K@F)"$#.:8.&;,C&>5C#BRBDU&`Z.GI;6VVVVV[>*HCR^
 M\NF5NTX(+ZG9!`'.RR';Q(I24)G8&F)ZV;5T-I<8^C*:PS$S>'GA,(3Y_XOO
 M,]/3T<WS?`[`M6>K!M/?O^E4+_;#B.R*>[]AB@]ZDA`A$D9%B`*`L@C]=JC`
 M"M!19!$4.DD]LD[6(;PB08P#]@N\LIZRU04H2%P[7U6I;M'>NZ_7A0]%_$@/
 ME;0\45/)V26T0OIJGW$##5,&M*2O<8LC)/G+'Q9##?:U@_0:SE//7D9O3WM;
 M50\1SQW9A)0XXL.QM_G&:2+I@0*DP@1"4>QIJ`2"9Z48^+AO@5NQ#A8E1)<1
 M>CCE##@WA&V4UZI<ES]3Y\<L536S5,KKI2!D0X%0R(E564$Z=3WXS-/MPFPM
 MO"M=B+99(#1`%!R%>L?<US'+0FJ$IC!D3HK*#97C,""#2'"$RP1]+F&!>.]-
 M14T[0NB#8$540BSZP^5DB^<`J`D)]8M`)P@'Z>6'QOU+5_*@`0(3[RRE5*6`
 M4+S"(GQ4V+=!TX2)Y]YY0MRJ=+'W88]O;0]1"WYL_'A[=N3!R[`:RS15`9%2
 M'-F^ZC/+%1V-W(X_?K')4+.6"B(10LE:"II)C!SZT\H(+-UY>+E&?S\50YD#
 M^8WY8+*PPLZB)NYXZ,3"U#VPO+VJTCXVBV-+!XO3QA:F?1=C!BE+&`FA8(6%
 MRBW#FLA90J7TUP$-`(D@L@+1]M<.]N7/(/[%,U=3\5+NPM%9<*\*X43V<;G-
 MS70IZ-OAO6ZI9T9N?$I7F<2)EW>,;/@7M>Y&58WMLO*G+'VMFF$T9;^`:`(&
 M1)$+AQ`+=<]`U3Y]1)`^<1/XCP^[11`)`_JBA4W!M!LL'V!+!;@G$#5>T,0"
 MX)!''U5\C,GT0^,:L_Z1#X_'Z,F6K+/Z!`*,D\Q)342.'6%K"7`?:R*]F[/8
 MGT0#=SZB:W::(8U9Y>.VVVVVVVVWQX["<FONZJXD*J84034A`2>VRLB8(!3.
 MDF]&!<D!-A%4;!,@%TSC&4'N9)%4&4-,['22PD$2R2E>=W5B,86>Y&>V!NZF
 M+.?-4B6D!%-VWH`T%<[8&<JQ>SZ36FDY;9V4^5BZ.8YU5FBQM20Z@Q8:T%9:
 MX+2Z25QK!K:T=V&H*&]A>BP#!0;44F#F$U@DJSSF830LQ*GM@HU<S,@!5!2(
 M(C-9[O%UM-0DDU%*DH)969`)I"%2HBO+;)'9VL5RI<V:@&$['19T$$M@'O?6
 M&!2IJM`0*@,K.47I%G6(IA2+&-!T3B[;[FYX:LX,PW.]>S8-4B.TB[M-T"]J
 M"XS,PP7\VNCIPN?3?N=?E^`N/F#['-8G(,8B=+&G;\URB&NS_&M.N+8"LG,W
 M=VP08(0)F/I68,A0@569#%%,._-\B0]<F8LK?&K<0J(_A5;.@"\F15[ESLJK
 MS9S(=^G+D&O>Z8'<7P20]ORG\\*D%GL?DC%4<%L8C_#&%<58,4E)(LA]/OR%
 M"&\LZ)/X53I@J$RSO%\!0)*!64"P5.#?$-U%X'(;^<=(2K*ZAM^YF3#R%L/Y
 M>U!;KO'<+%`E0*E2JC,3T<3WI]ZJVF'3WZX&MJ`4B64#+\,#8JON@.0,1>@<
 M.-($2038!2031:2WV;7)`U9O-Y**E0DVZ^FGB%"=WZ.LOKOP3AT0+!J(4]:_
 MR.@;$\UG8G?TZG!7>*!B&]7<KM'9P-C%,Q"BP=O%DEL9$5$55115.<SY9VY#
 M494@;(;>62;&(ENBNU[D#6&ZJD*B=R:#^D-CJ&?+IN!QYE=312NGZ6>BII@9
 M/YEU]JQ;IT0D.T=H9'=>IE_]8"X13"5K1@HLJ5E06"(Z&`QX7HY6+P`K!YR\
 M(2=T-^.8T:IE%5W"&G;W>>U';`U\P.?A.?I)SY.3PX('(#V;N=5YCBW$V0XR
 M<>X-'@9BAM@>TS1A2T8,F%+3GZ>>VJQ1Z!'$QW@6H0T@2/.@P7>%(X&PS5`[
 M$<J`1X`-GU'R]F#[DY#JI$.X\C4#'Q+%..G)'UXR22555"`%HMA+:C`ME`M+
 M`+?<>Q"PYT3\X!V/<:\*.[WKNW"&O'JD!YW1-W44#N11VO@&@>X<N#BE'(MN
 MTPE$A)L`]VJEK%#ZD#(MN938V*"YR@Q?BPI0<D<..BA;B,-I<O/!GVJ:A54^
 M=Y![<34K;4T2/H_3SEEZF@.M(G4.J@<3OVN0%X+YJEG+S*OHGB\#U3.$0SD,
 M]D$VR3,2;\PW\!8HJBJL)Z=608?9;B#D(Q3V<C1/]?J^K^FI!:*_/8NOOT!\
 M]_@`%1D!T<W.2]".9+HN%,9:.G@O$CS,F#:Q:3G)([2=(YFN7EI$S<GJC@U;
 MF^WLQLK!"/8C%@.RF"&,315/>00WB&`W=""<8<2)8@$$-W=99FH3`4ATS92:
 MIV-OR?<_`]K+)/X"%EL[.F=^J`+%.P8@G90#:8#$B%(,(62HL/]K&)_C\RAM
 M0+E95F?5NOQ,',38SL9\OTA$,FN;+>23,P'MJY;\V[5W'!@@2)(2P-J7+#D6
 MK,A([5H&MVH%?11<+&\2B4Q9-0S(@:`7VF(9:R:A8@(/12\^N/9F)=DF4X3:
 ML"X$-VS8NT##`CJ9B%+D09(4_8G`3CUZ8E!=L#N3,H?T75X?QIV\"_%.W^CI
 M^4RX!A2`7.!LA^2<RW[;H[YR$_`91#4S30'13`R+COX=E@'[QCWYKN#KL+=+
 M(6L'IU"X'[1#CW8?A?_91(1ES7EO#U#9(ABA:`WO4+,($*($J23NP);$.M.'
 M]QJ#=S^&\K@(9@,[LEQ&8&]7#%80\U&PU"1D`O^,D7O:/E>9&)I19Q\32/_P
 M7[5,`#OVV0.A%G1+0$K@E\1U7)#-G4J67%QQTNK+$&6KE&%DRO-I@GDQ#"!V
 M"!D+F3CN$T"DH[S-$D,=*&LUY>!!016&>Q@&U1P-L$"<S]0#R>DMJ[M@'R:I
 MM*),OU=]6O@OA`-RYP4/R+WU;$JL^X/`YN(4@8H'4[K$W:)F%BT9/W0J65(_
 M/`X\@7!L&GB.0RFQ/)A#%J:*.G;`RRR8#S2T*B;\ZX"(@6393A#+>"-)@8EQ
 M@L+L(6N2PK;1#7Z*2YZ7W6=^!$M:DB[>("<\$H5QQ-3T,>.8<QM6LF`H>NF:
 M:T@:E<D":9R_,=!QV8,4%R*AXT1$0<-!T[J:2Q7.@Q'%4Q)`:)C)*6H'XR+B
 M(F*?+HMP,\%J6B=4,<*A>6"2(1L@981P"8IS6;L?-/0A\WQV`AMBYP@8S'?9
 M2PK?MP6]K:V[_A79B<%LD2NCZH6G*Y>X-^RSL@7GE0EO;ACD!%TWFA)Y1L<$
 MJIDUDK*(8R8H<<QV/-1[^M*M4+YE!2!#M7C0:&IOY805A!2$%2+'T$,>'HF!
 MTMR*U,+U!PM>]%%511+%VK%TA5[,,.IJON.]$/#P8GS51(!"$8):XH0#=P+&
 MJIPD[O<@;5"RN0*0-P>O"F>V351R%>S:/+T6&O3C8HY3T[O?R`,N_K;N0D$@
 MZFT[2+D;@,.P,O'-OTNB&T-E>,&+"3JL@$*XB]Y>W928AV!`3-$W\/"8B11$
 MMH5J5*,J5GT8PN"VF&5(XH""2*30Q'B\>W240,`P8B,8BK%$9*]_OM#SI-4U
 MN[5=X@88$+?;Q+$/WAV>1R7KZE6>\?A5*&$O[1"I?2J*6A"%-H*3%JQ99(US
 M`A2%R`NX,(&.V''4^#D<)KLK&63G0G,TXO8;3Q4=OL/D,.5X+E8$`1`T&D!#
 M`B0?T"!P$)F9(3RY;]TYERI3!A#;N#;L8#`616(3$BM*&[<%CV$3]>^@\LT#
 M9L+AP!P[,'QQZ;5SFH5K:+P6%6"KL_7Q+7N81;!RO2"2M-@&^I))M+1"O6^_
 M#)1S\%VIYGVEWJA;%!Q2)#>)2Q(C%(\6N&H8V4P<EQJ@)`HJP!1+E[@&TQG7
 MN(2;<"#X8^IQWB@%T-&LO'(#8CBF!SO%[M+<O3Y#'(^?Y5^1`WHD$V@&MAL*
 M>WIR.#[B*3Q,R&WM>Z5L-ANV=;=QBFO=OY_<PZ><QN>1@5X&D2Q"9"@62TZT
 M6'ON#%OCP6L,)B@RJ:CP:]H^<\HQ5555445@I%0BL5&,(LM"P%/(2<AW"@9[
 M.K.\12[[3G2G!:6\;1KS@X"Q<KQP^QW$D)A#,S:N8G&^V`TEY(;BV6X$T=_A
 M*0YCH.9QJXBUJ':DAW"=S'"-0=DPM)&>XE2TU+7M-2@/N+H'1+'J:'5!A^.!
 M[-YS6GU5MKP(IO+&.1]*]AX&%1&X.#2<^*\8%',E)Z!IB99F?0"(IE249J"_
 M?`(-_AQ.T7&0W$<P_A#9Y^!#>&6]-XY``(C0`#%`$6(!`T5=X\S%><B;M)::
 M64ZW2-Z)#6_R6UQJ00Q\+$QE;8)',H3':*>JP`,[7DSL>P.R.]-,Q'<<P9R,
 M)"21A#KSD*!NX&8L!B:QJ*L-B5'!P#$QWU4!G-<@;6X\[7M:BZVX7+GH8!_O
 M`\(]BZB&D#DZ\QD$-P>]8L6+%BQX^1&2$@MRH1#0##F=3!,HE^^E(I^TV7SY
 M.(R%[FP\D:G&"5ZT8V^%'7NAEAUJNN?'WD#C`D$$B`,B"9E%/+3-1551#;K=
 MC-/)F7SO/T.GCA>J)U9KC`>#,#G$[@Y/0BQM9T="*EK:7J1QSK2'L,<9+'D]
 MYU*(9T#KQ$,@$KTW(7*3(S(W0Q-HS:97+;+/OAPJBJTX7B$E1TJ(E*D00...
 M1#LCHA;Z'H`VG(9T4>AIFZ7R-SN,ER$O$'"C.I"`DDP,-]&B3NZV\:INO>9(
 M^.&!VB[?@=3N/"$@A[]]>U=[O`)#@IWT`8'0P=\29X(/BH^`8:*\`#;\^6$=
 M"L;:<%[R:!^Y=QGWYD7J<48&VZ8+3L)`Q?-N,AM_8OB(:PA!FP(M`$6)W-:V
 MQBT1?+V]EPL)NGL\J2K4+:QNPA&$DVIX5F.OPW%<UR[,2M#ZBSEQ,/RZ+1>K
 MI"@H)XR/G7O&*'[YD*I7<B'FY9Y62'N/J"6`@D#`<X"(L]-L/5D'_%W)%.%"
 %0%.M-3P`
 `
 end
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 12 Jun 2004 12:17:43 -0400

 At 2:49 AM +0200 6/12/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >
 >>  Please be a little patient with this whole process.  This message
 >>  took me two hours to write (as I cross-checked things), and I
 >>  haven't even *done* anything yet!   :-)
 >
 >I also take some time to answer this one :P
 
 This is not a competition to see who can put in the most time on
 a set of updates.
 
 The only reason I made that comment was to ask for patience, because
 I expect that you are very eager to see all these issues worked out.
 That enthusiasm is great, but *I* still have to go through this
 slowly so that I understand all the issues, and I make sure to follow
 all the "standard practices" for upgrading files in the base system.
 And I still have a lot of other projects that I have to work on, so
 I do not have a lot of time that I can devote on this.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <root@gits.dyndns.org>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 13 Jun 2004 00:20:22 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 2:49 AM +0200 6/12/04, Cyrille Lefevre wrote:
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >
 > >>  Please be a little patient with this whole process.  This message
 > >>  took me two hours to write (as I cross-checked things), and I
 > >>  haven't even *done* anything yet!   :-)
 > >
 > >I also take some time to answer this one :P
 > 
 > This is not a competition to see who can put in the most time on
 > a set of updates.
 
 I'm not competing at all. but as you stated, the provided updates
 where not as up-to-date as they should against -current. so, to
 facilitate *your* work, I provide a new set of updates up-to-date
 as they should at the first time.
 
 > The only reason I made that comment was to ask for patience, because
 
 that's why I said to you, in the same email : take your time.
 
 > I expect that you are very eager to see all these issues worked out.
 > That enthusiasm is great, but *I* still have to go through this
 > slowly so that I understand all the issues, and I make sure to follow
 > all the "standard practices" for upgrading files in the base system.
 > And I still have a lot of other projects that I have to work on, so
 > I do not have a lot of time that I can devote on this.
 
 I know you are involed in a lot of projects, as I am, too. and I'm not
 devoting all my time to FreeBSD ps, even if you believe it.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 13 Jun 2004 17:04:42 -0400

 So, here's some feedback on the much larger patch that you have
 for `ps' itself.  I am afraid that what I have to say is not
 completely what you are hoping to hear, so let me start with a
 few general comments before I discuss specifics about the patch.
 
 I will have a lot to say here, and I will split it into multiple
 messages.  Please don't try to respond to any of it until you
 have the time to read all of it.
 
 Based on the first email that I saw from you on these changes
 (before you sent in the PR), this is a version of `ps' that
 you have been working on for the past two years.  As a result,
 what you sent in is a single 5,000 line patch for `ps'.  It has
 some good parts and some bad parts, but all those parts are mixed
 together in one single massive patch.  While I appreciate all the
 work that went into this, the way you have provided this (as one
 single massive patch) makes it almost impossible to work with.
 
 The thing for me is that I can not simply apply this update, see
 if it compiles, and then commit it.  I have to look through all
 of those lines, and make sure I understand everything it does, and
 all of the side-effects.  I must do that, because there are several
 other FreeBSD developers who will grill *me* over every line once
 I commit it.
 
 In my case, my own recent updates to `ps' and `newsyslog' are a
 little larger than I would like, but it would be a mess to break
 them down farther.  However, it is my intent is that no single
 update of mine should be over 1,000 lines (unless I am adding a
 brand new source file).  That is the way I work on my stuff, and
 I am not going to break that rule for something that I did not
 write.  Records indicate that I have made about 425-450 commits
 to the base system, and a quick skim of those show that I have
 had maybe 15 that were more than 500 lines, and it *looks* I
 have zero that are over 1,000 lines.  That suggests that this
 5,000 line update needs to be broken up into at least ten
 separate updates.  It will take time, effort, and testing to do
 a good job of splitting it up.
 
 Not only is that the way that I (personally) like to work, but
 that is also the way that FreeBSD committers are expected to work.
 If you check the cvs-commit email for the base system, the majority
 majority of commits make fewer than 1,000 lines of changes.  Yes,
 there are exceptions, but not many of them.  There are exceptions
 when importing pieces of 'contrib' from other open-source projects,
 and there are exceptions when the nature of the change is such that
 it really must be done as a single large update.  This patch to
 `ps' does not meet any of those reasons for making an exception.
 
 Even with the smaller commits that I do, I have other FreeBSD
 developers who pester me to break up my updates.  For a variety of
 reasons, it is much easier on *everyone* if a single commit does
 just "one thing", and that "one thing" can be completely described
 in five or ten lines for the commit message.  The summary that you
 initially provided for this patch is over 500 lines, and you have
 been adding things to that since the original PR.  Note that your
 *summary* is larger than 95% of my commits!  That is way too much
 going on for a single patch.
 
 Please note that I do appreciate all the work that you put into
 this, and all the other work that you've done for FreeBSD (which
 I noticed when looking at your many PR's).  However, this massive
 patch really must be broken apart to be usable, and it will take a
 fair amount of effort to do that.  My own schedule is such that it
 will take a some time to break out the parts I want and install
 them.  So, please be patient with the process.
 
 I expect that you have at least 10 years of programming experience,
 and I expect that means you have a pretty good idea of just how
 much work it would be to rewrite this single massive update into
 manageable pieces.  Since it will take a long time, I am not going
 to put my other work on hold to rush through this.  The more I try
 to rush through this, the more likely we will be breaking things
 instead of improving them, and that will just get all the other
 developers mad at me.  I would not like that.
 
    My next reply to this PR will get into some specifics of what
    your patch actually does, so that you will not feel like I am
    dismissing your work without having looked at what it actually
    does.  Please read that before replying to this message.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 13 Jun 2004 17:10:58 -0400

 [hopefully these 3 messages will arrive in the correct order!]
 
 Your patch has many different things going on, some of which are
 good, and some of which are not so good.  The big problem is that
 all of these different things are happening in a single patch,
 and the result is such a large patch that it is impossible to
 write a short summary which accurately describes it all.
 
 It should be mentioned that I had never worked on `ps' before
 this year, so you should not worry that I "own" it.  But I do
 feel like I "own" the parts which I have committed.  I did work
 hard on some of my fixes, and I do not want to see "my" fixes
 get thrown away unless there is some obvious benefit.
 
 As has been discussed in various email messages, we also have
 problem that I just happened to start work on `ps' just a few
 weeks before you first mentioned your work on a mailing list.
 Before I had seen anything about your work, I had already been
 discussing my set of changes on the mailing lists for week or
 two, and was even starting to commit my changes.  When I picked
 up this PR back on May 22, I stated that:
     I'll be looking into this (as I have time), since I have
     a bunch of other changes that I'm working on for `ps'.
 
 I still have work from *that* time which I have not committed yet,
 partially because I first wanted to look through your update, and
 partially because of many interruptions from other projects that I
 work on (mostly with my real job, which unfortunately has nothing
 to do with FreeBSD).
 
 I have now looked through some of your changes to the ps.c file,
 and here are some things I have noticed.  What follows is several
 unrelated observations of various things that I noticed while
 skimming over your patch.  It is not well-organized...
 
 First, a very minor nit:  This PR mentions:
      FYI, here are the ps sizes once compiled w/ -O
      and stripped :
          -current : 38048
          this one : 38760
 You have already corrected in later emails (one if which ended up
 in the audit-trail of this PR), but I just thought I would note
 that those numbers are not right.  Right now, /bin/ps on my own
 freebsd/i386 system is only 31208 bytes, not 38048.  Also note
 that before my recent work on /bin/ps, the executable was closer
 to 28000 bytes.  I actually want to see if I can get back to the
 smaller size, instead of having the size increase even more.  (It
 is very likely that I CANNOT do that, but I would LIKE to! :-)
 
 You have many different unrelated changes going on.  Some of them
 are very good to do, even if they did not fix any bugs or provide
 any new features.  For instance, you have changes to use
 the <queue.h> macros:
 
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
   		if (strcmp(vent->var->name, v->name) == 0)
   			return vent;
   	}
 
 However, the update also makes some cosmetic changes which *add*
 "style errors".  Code in the base system should try to follow the
 advice in 'man 9 style' as much as possible.  A lot of the source
 does not due to historical reasons, but when making large changes
 to some source file we want to make it CLOSER to style(9).  Your
 large patch includes changes like this one:
 
   static void
 -saveuser(KINFO *ki)
 +saveuser(kvm_t *kd, KINFO *ki)
   {
 -
   	if (ki->ki_p->ki_sflag & PS_INMEM) {
 
 That blank line is there because the routine has no local
 variables.  Blank lines like that are explicitly recommended
 by style(9).  The patch is removing it, which is a "style error".
 
 Your initial patch was based on an earlier snapshot of the source
 code to `ps', and as such I ran into a number of errors when
 trying to apply it.  You have now supplied a newer patch, and I
 had no errors when applying that patch.  The problem is that you
 apparently made that new patch by simply comparing the source
 that you already had with the latest source of `ps'.  This is
 not good.
 
 For instance, the patch completely removes all the fixes which I
 just added to kludge_oldps_options(), with no explanation as to
 why that needed to be done.  This is a routine that I pretty
 much rewrote, with some input from other developers, and it looks
 like the patch removes all that work simply because you didn't
 take the time to check what that was doing when you generated
 the newer patch.
 
 The newer version of the patch also re-introduces the old
 BACKWARD_COMPATIBILITY hack, thus undoing revision 1.92.  That
 was a change which I publicly discussed on freebsd-arch before
 I made it, several people liked the idea, only one person said
 anything against the idea.  The change has been committed, and
 has even been partially MFC'ed into stable.  When I asked about
 making this change, *you* were the one person who said the
 change should not be made, and the only reason that you gave was
 that it would be nice to keep backwards compatibility. That is
 true in a general sense, but this specific change has already
 been agreed to by many people, and it has been committed for
 almost two weeks without any objection.  I even had people
 request that I make it easier for them to get this change on
 4.x-stable, so I did that.  I see no reason why that commit
 should be undone, and the PR does not mention any reason.  I
 suspect that this is just an oversight when generating the new
 patch.  This is one of the problems with working with such a
 massive patch, because other developers will be making changes
 at the same time you are working on all your changes.
 
 The patch also reverses at least some recent changes to the
 pscomp() routine.  In the PR, you do mention that the patch fixes:
   "pscomp() getpcpu * 100 or always 0.
             also, uses typed variables instead of an
             integer generic one which is more cleaner."
 but with all that is going on it is not clear if the patch is just
 fixing the same bug that Bruce Evans (bde) fixed in revision 1.81.
 It is possible that there is still some bug there, but I compared
 the sort-result of your `ps' against what we have in 5.x-current,
 and the sort-order is exactly the same in both.
 
 I know that you also wanted to reduce the number of lines in that
 routine.  Your changes do that, but while the result has fewer
 lines, IMO it is less readable.  In any case, almost all of that
 routine was recently rewritten by Bruce, and I am certainly not
 going to delete his work just to commit this patch.  Also, Bruce
 and I have discussed making a different cosmetic change to the
 routine which would make it both shorter and more readable, but I
 haven't finished that update yet.
 
 The patch also undoes other recent changes.  Some of them are
 undone because you liked having a large switch statement, and I
 greatly prefer having a few small routines.  That specific case
 is a judgement call, but given that I *just* wrote that code
 the way I wanted to write it, I am not eager to throw out all my
 code simply because you wrote some similar changes in a different
 style when you worked on your changes.
 
 The patch undoes other recent changes, but I am not going to try
 to cross-check all of the recent commits to ps.c, and I doubt it
 will help anyone for me to write them up.  You said you initially
 did this work two years ago, and I just don't have the time to
 cross-check every update in the past two years.  There is really
 just one basic problem, and that is the patch has to be REDONE
 based on the present source.  And it needs to be a bunch of
 separate updates, each of which is only changing what needs to
 be changed, based on the most-recent source.
 
 The patch includes the parseopts routine, which includes the
 scary line of:
 
 +	static char bsd_fmtstr[] = "\
 +label:[0Z] user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:[02]! \
 +ppid:[jl] pgid:j sid:j 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:[01]! \
 +tt:[jls]([du]!)& start:u time:[01]! sl:v re:v pagein:v vsz:v([lu]!)& \
 +rss:v([lu]!)& lim:v tsiz:v %cpu:v(u!)& %mem:v(u!)& command:[01]! \
 
 I look at that, and I simply do not like it.  I know it will take
 me some time to read the code just to understand what that string
 is doing.  That means any developer who needs to change that code
 will also have to spend a some amount of time trying to decipher
 what that string means and what they need to do for whatever they
 want to add to it (or change in it).  At the moment, I am not
 convinced that change is worth doing.  (I may change my mind
 after I have some time to examine it, of course.  Right now I am
 just explaining why this 5000 line update MUST be split apart)
 
 The update includes a change to greatly improve how multiple
 output options are handled.  I like that idea a lot, but it is
 mixed in with so many other things.  I had noticed some of the
 same problems you noticed, and I have an update which fixes
 some of those issues.  It looks like you have spent a lot more
 time figuring out how the options should interact, and I think I
 am at least going to take advantage of that by seeing if I can
 get my update to print columns out in about the same order.  I
 am going to do that by just comparing outputs, though, because
 that will take me less time than trying to figure out and
 extract the part of this that I am interested in.
 
 The patch adds a number of "posix" improvements.  It was always
 my intent to finish more of what I started with revision 1.67
 of ps.c.  That's why I still have some sections in the option-
 processing which implement some option, but the section is #if'ed
 out.  At the time I stopped working on my larger update, pulled
 out the part of that update that I knew I could commit right then,
 and that I felt I could MFC in time for 4.10-release.  I have put
 my remaining updates on hold while I looked at this.  Now that I
 have looked at this, I intend to finish what I was doing and see
 how people like that.  It will be faster and easier for me to
 finish that work, than it will be to sort out all the many
 different issues in this one massive update.
 
 My goal was similar to yours, but my update for it is certainly
 much less ambitious.  Your update refers to many "posix" options.
 In my case, I am working from the official released standard of
 SingleUnixSpecification, version 3.  I do not have the latest
 POSIX description of `ps', but my understanding is that SUSv3
 is supposed to be exactly the same as POSIX.  (it would not
 surprise me if I am wrong about that).
 
 The patch includes sections like:
 	/*
 	 * posix (hpux) : -C cmdlist
 	 *	select processes by command name.
 	 * bsd : raw cpu usage instead of the average one.
 	 */
 I personally have no desire to end up with a version of `ps'
 which implements every option known to any other operating
 system under the sun.  My concern is that will make `ps' much
 larger than it needs to be, and that very few people will
 actually benefit from it.  Furthermore, I suspect it will just
 open us up to a long string of PR's where someone says "You
 have this option from IRIX, but you have not implemented it
 exactly the way IRIX implemented it" -- at the same time some
 other person complains that the exact same option does not work
 the way *solaris* implements it.  I do not think we can be all
 things to all people, and I think it will be a big waste of
 time for us to try.
 
 What I intend to support is just two main modes.  The first
 mode is "Whatever *we* want as options for a BSD `ps'", and the
 second is "Whatever is described in the settled standard of SUSv3".
 That will still be a huge step forward from where we are.  After
 we get to that point, we can certainly look at additional ideas.
 I actually want to add a third mode, which would be "SUSv3 plus
 a very few safe extensions".  I imagine that could start an
 endless bikeshed, but I did implement `-s sidlist' (as seen in
 solaris/aix) because I have wanted it in the past, and by golly
 that option should be *somewhere* even if it *does* conflict
 with NetBSD!   :-)
 
 Please note that this does not mean that I would never add more
 options, such as the ones you have implemented.  It just means
 that I do not believe they must be added all at once.  We can
 split this into several updates, and commit them as time permits.
 I also think it's important to ask other FreeBSD developers what
 they want, although I fear we have already talked so much about
 `ps' that some developers wish that I would just shut up about
 it for a few years.
 
 Your update also improves the handing for '-t <ttylist>', and I
 like that idea a lot.  That is only a small part of your update,
 and I expect it would be easy for me to pull that part out and
 commit it.  I hope to do that as soon as I get the chance.
 
 I notice some changes to define routines with "const" where
 appropriate.  I know some developers hate "const poisoning", but
 I personally like to do that (as long as it is does not complicate
 the code).  I have not looked closely at all you did there, but
 "in general" I am in favor of such changes.
 
 I expect you have several other good ideas in here, but they
 need to be split out into separate updates so that each update
 can be evaluated on it's own merits.
 
 This is not an exhaustive list.  It is just what I noticed when
 skimming through the patch.
 
    My next message will describe a few remaining things that
    came up when I tried to compile `ps' with your patch.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 13 Jun 2004 17:14:46 -0400

 [3rd of three messages in a set from me for today]
 
 So, enough of just looking at the update.  I then applied your patch,
 and tried to compile everything.  While you have no way of knowing
 this, it happens that I compile `ps' with several extra warning
 options.  I am not ready to change the warning level in the base
 system yet, but I test with these extra options in CWARNFLAGS while
 I am compiling it on i386 and sparc64, and right now the source in
 5.x-current compiles cleanly with the extra options.  I will change
 the warning level in the base-system version after I'm sure that it
 also compiles without errors on all the other platforms, but I am
 in no hurry to do that.
 
 In any case, this unfortunately means that I get a number of compile-
 time errors with your patches that you would not see.  That is
 something else I would need to clean up to commit this big patch.
 That is not hard to do, of course, as there don't seem to be too
 many problems. But it is just "one more thing" that I would have
 to do if I were to commit this patch as it is.
 
 The flags I use are:
 
 WARNS?= 0
 # ---
 # The following is an extension of BDE's recommended CFLAGs.
 #
 CWARNFLAGS?=    -W -Wall -ansi -Wbad-function-cast -Wcast-align \
   -Wcast-qual -Wchar-subscripts -Winline \
   -Wmissing-prototypes -Wnested-externs -Wpointer-arith \
   -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings   \
   -Werror -Wno-format-y2k -Wreturn-type -Wswitch -Wsystem-headers
 #
 # cannot use on 5.x-current:         -Wnon-const-format
 # ---
 
 (some of those are probably excessive, but I just keep copying
 them around and only delete one if I find it is annoying me
 with messages instead of warning me about any real issues).
 
 In any case, I wanted to go thru your patch enough to decide what I
 want to do about it.  I still intend to pick up some of the kern-
 level changes, and I'll pick out a few small changes from the big
 ps-related patch.  In general though, I am going to return to the
 changes that I had started on back in March, polish them off, and
 commit them.  And then we can figure out what should be done as
 the next set of updates.
 
 My updates certainly do not do everything yours does, but then
 yours does not fix all of the things that I wanted to fix.  So if I
 apply your update, I then have to do even more work to rewrite the
 changes I have *already* written up, and that I presently just need
 to polish off.  My earlier round of major changes ended on April 4th,
 and now that I have some free time I want to move forward with my
 remaining changes.  I am not doing that to annoy you, and I am not
 doing it to "re-invent the wheel".  I am doing it because it is the
 easiest thing for me to do, and because this massive patch has too
 many different issues with it.
 
 I know you have already worked a lot on this patch, and I know you
 are eager to fix the patch if that will get it committed right away.
 But right now I do not want you to spend even more effort to try and
 address every single issue that I have just described, when I know
 that I will be committing more of my own updates before I get back
 to these changes.  However, I do like parts of this patch, and I do
 expect to get back to you after working on my pending updates.
 
 I do feel bad about how this is going to work out, but it just
 happened that I started to work on `ps' before I knew anything
 about your work.  Initially I just wanted to fix a single error
 message that was printed when I did not want it.  If I had known
 about your work, I would have just fixed that one error, and then
 left the rest of this for someone else to work on.  I would not
 have picked up this PR at all, because I have already promised
 so many things on so many other little projects that I would not
 have touched `ps' if I knew anyone else had been working on it.
 
 So this is my plan.  I also plan to pull in a few things from your
 large `ps' update, and some more of your kern-related changes.  I
 am happy to credit you for the things I commit from your work, and
 I did do that for the few kern-related things I already installed.
 I do appreciate that you have done a lot of work here, and that
 you've even done more work here than I have done.  But that does
 not give me any more free hours in *my* week, so I have to pick
 out projects in much smaller chunks than 5000 line patches.
 
 I doubt that any of this makes you feel any happier, but I felt
 you at least deserved a more detailed answer before I decided
 what to do with my pending patches vs your larger patch.
 
 Now I just have to find the time to finish off my patches!
 [actually, I hope to apply a few of your kern-related patches
 first, as I expect that will make things easier for both of us]
 
 I am done with all I wanted to write up on this PR for this weekend,
 so now I will sit back and wait for your reaction.  My fear is that
 you will be just as willing to type a long reply as I was to type
 these messages!   :-)
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, cyrille.lefevre@laposte.net
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 13 Jun 2004 18:01:15 -0400

 At 9:20 PM +0000 6/13/04, Garance A Drosehn wrote:
 >  My goal was similar to yours, but my update for it is certainly
 >  much less ambitious.  Your update refers to many "posix" options.
 >  In my case, I am working from the official released standard of
 >  SingleUnixSpecification, version 3.  I do not have the latest
 >  POSIX description of `ps', but my understanding is that SUSv3
 >  is supposed to be exactly the same as POSIX.  (it would not
 >  surprise me if I am wrong about that).
 
 I see that I forgot to complete what I started to say here...
 
 The patch adds a lot of options which it describes as POSIX items,
 but which are not listed in my copy of SUSv3.  For now I want to
 stick with the smaller list of items which I see described in
 SUSv3, and not add too many additional options.  That way, when
 SUSv4 is decided upon, we will not be likely to have options
 which conflict with whatever options they decide to add.  That
 is just my opinion, though.  Once we get some of these other
 things done, we can ask other developers what they would like
 to see...
 
 Also, it is probably true that I have written more than I needed
 to for this PR.  But I know you put a lot of work into these
 changes, and I did not want it to look like I was ignoring all
 of that to just blindly return to my other pending updates.  I do
 want to pick up much of your work, but the result is probably
 going to look a lot different than the result of this patch.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 15 Jun 2004 13:27:19 +0200

 "Garance A Drosehn" <gad@FreeBSD.org>
 
 Hi,
 
 ok, I've just read all your messages, and I'll try to selectively
 answer to them all at once.
 
 <first message>
 [snip]
 > Based on the first email that I saw from you on these changes
 > (before you sent in the PR), this is a version of `ps' that
 > you have been working on for the past two years.  As a result,
 
 well, preciselly, I worked on two years later, then sit until I saw
 your plan to commit some changes. so, I reworked a lot what I've
 two years ago. this rewrite was essentially a full cleanup (undoing
 unnecessary changes) which includes some bug fixes plus some extra
 stuffs from other oses. the rest was already here since the beginning.
 
 > what you sent in is a single 5,000 line patch for `ps'.  It has
 > some good parts and some bad parts, but all those parts are mixed
 > together in one single massive patch.  While I appreciate all the
 > work that went into this, the way you have provided this (as one
 > single massive patch) makes it almost impossible to work with.
 
 let me know precisely what you wanted first, then I'll provide them
 you as separate parts. It would be more easily for me to do the job
 since I far better know my code than you could. for example :
 
 0) kernel changes (except PROC_NOSYSTEM for instance) (small to medium)
 1) queue(3) changes (small to medium)
 2) kvm_t + variable relocation (global -> local if any) changes (small)
 3) const changes (small)
 4) bug fixes if any (I know there are some not fixed yet) (small)
 5) -t enhancements (small)
 6) keyword table changes (medium)
 7) SUSv3 options + keyword updates (medium)
 8) extended options + keyword updates (medium)
 9) auto-field-sizing + -k sort option when available (big)
 *) etc.
 
 well, I'll try to post a better plan (much more detailed) whenever possible.
 
 [snip how FreeBSD commiters work]
 
 > I expect that you have at least 10 years of programming experience,
 
 you are right :)
 
 [snip]
 </first message>
 <second message>
 > Your patch has many different things going on, some of which are
 > good, and some of which are not so good.  The big problem is that
 
 
 [snip]
 > As has been discussed in various email messages, we also have
 > problem that I just happened to start work on `ps' just a few
 > weeks before you first mentioned your work on a mailing list.
 
 well, it's my fault to not have submitted my changes before.
 however, the recent rework I've done if far cleaner than the original
 one. also, it takes me some time to wrote what's changed to permit
 this PR to have any chance to be commited (at least some parts).
 w/o that, since the PR is somewhat big, it would not have any
 chance to be seen.
 
 [snip]
 > I still have work from *that* time which I have not committed yet,
 > partially because I first wanted to look through your update, and
 
 thanks.
 
 [snip ]
 > First, a very minor nit:  This PR mentions:
 >      FYI, here are the ps sizes once compiled w/ -O
 >      and stripped :
 >          -current : 38048
 >          this one : 38760
 > You have already corrected in later emails (one if which ended up
 > in the audit-trail of this PR), but I just thought I would note
 > that those numbers are not right.  Right now, /bin/ps on my own
 > freebsd/i386 system is only 31208 bytes, not 38048.  Also note
 
 I am pretty sure I sent an email to correct what I said. in fact,
 -current was compiled w/ -g and "this one"... this explain that.
 
 > You have many different unrelated changes going on.  Some of them
 > are very good to do, even if they did not fix any bugs or provide
 > any new features.  For instance, you have changes to use
 > the <queue.h> macros:
 > 
 > - for (vent = vhead; vent; vent = vent->next) {
 > + STAILQ_FOREACH(vent, &varlist, list) {
 >   if (strcmp(vent->var->name, v->name) == 0)
 >   return vent;
 >   }
 
 as I remember me, such changes where requested by a core team member
 two years ago (don't remember exactly who).
 
 > However, the update also makes some cosmetic changes which *add*
 > "style errors".  Code in the base system should try to follow the
 > advice in 'man 9 style' as much as possible.  A lot of the source
 
 as a general rune, I try to follow style(9), but style(9) is somewhat
 large and it's not as simple to always remember what's detailed there.
 
 > does not due to historical reasons, but when making large changes
 > to some source file we want to make it CLOSER to style(9).  Your
 > large patch includes changes like this one:
 > 
 >   static void
 > -saveuser(KINFO *ki)
 > +saveuser(kvm_t *kd, KINFO *ki)
 >   {
 > -
 >   if (ki->ki_p->ki_sflag & PS_INMEM) {
 > 
 > That blank line is there because the routine has no local
 > variables.  Blank lines like that are explicitly recommended
 > by style(9).  The patch is removing it, which is a "style error".
 
 I also usually try to reduce the differences whenever possible by
 checking the cvs diff output such as the above one. however, as
 you said, this PR is quite large, and it seems I forgot some of
 those unnecessary changes.
 
 > Your initial patch was based on an earlier snapshot of the source
 > code to `ps', and as such I ran into a number of errors when
 > trying to apply it.  You have now supplied a newer patch, and I
 > had no errors when applying that patch.  The problem is that you
 > apparently made that new patch by simply comparing the source
 > that you already had with the latest source of `ps'.  This is
 > not good.
 
 you are also right here, I did not merge-in recent ps changes.
 I just provide you a patch which permit you to regenerate the
 initial code plus the following updates I've done since (which
 are not all recorded into gnats) as you clearly said that gnats
 seems to be incomplete in number of ways.
 
 > For instance, the patch completely removes all the fixes which I
 > just added to kludge_oldps_options(), with no explanation as to
 > why that needed to be done.  This is a routine that I pretty
 > much rewrote, with some input from other developers, and it looks
 > like the patch removes all that work simply because you didn't
 > take the time to check what that was doing when you generated
 > the newer patch.
 
 well, I didnt' really remove the recent changes, I didn't merge
 them, that's all. sorry about that.
 
 > The newer version of the patch also re-introduces the old
 > BACKWARD_COMPATIBILITY hack, thus undoing revision 1.92.  That
 [snip]
 
 also here, the recent changes have not been merge, so, don't care.
 however, as said in a previous email, IMHO, if you wanted to
 find more than one process by it's process ID, you are to fix
 your script, not the command. that is, use "ps -p xx,yy,zz" or
 "ps -p "xx yy zz", not "ps xx yy zz" which is totally not portable
 against other oses. at least, the old backward compability would
 have to be kept if yy and zz don't look like as process ids.
 I'll see how to handle this when I'll have time.
 
 > The patch also reverses at least some recent changes to the
 > pscomp() routine.  In the PR, you do mention that the patch fixes:
 >   "pscomp() getpcpu * 100 or always 0.
 >             also, uses typed variables instead of an
 >             integer generic one which is more cleaner."
 > but with all that is going on it is not clear if the patch is just
 > fixing the same bug that Bruce Evans (bde) fixed in revision 1.81.
 
 this comment was relative to my initial submission, not to -current.
 I'll try to be more clear in my futher comments.
 
 > It is possible that there is still some bug there, but I compared
 > the sort-result of your `ps' against what we have in 5.x-current,
 > and the sort-order is exactly the same in both.
 [snip]
 
 as said before, I intend to import netbsd auto-field-sizing which
 will include -k sort option since they are very close (parsefmt()
 vs. parsesort()).
 
 > The patch also undoes other recent changes.  Some of them are
 > undone because you liked having a large switch statement, and I
 > greatly prefer having a few small routines.  That specific case
 > is a judgement call, but given that I *just* wrote that code
 > the way I wanted to write it, I am not eager to throw out all my
 > code simply because you wrote some similar changes in a different
 > style when you worked on your changes.
 
 I've also planed to mergethis part of the code, but i's not done
 yet. however, we still conflict about the handling of spaces vs.
 commas :)
 
 [snip]
 > The patch includes the parseopts routine, which includes the
 > scary line of:
 > 
 > + static char bsd_fmtstr[] = "\
 > +label:[0Z] user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:[02]! \
 > +ppid:[jl] pgid:j sid:j 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:[01]! \
 > +tt:[jls]([du]!)& start:u time:[01]! sl:v re:v pagein:v vsz:v([lu]!)& \
 > +rss:v([lu]!)& lim:v tsiz:v %cpu:v(u!)& %mem:v(u!)& command:[01]! \
 > 
 > I look at that, and I simply do not like it.  I know it will take
 > me some time to read the code just to understand what that string
 > is doing.  That means any developer who needs to change that code
 
 don't you receive an email I sent you which may help you to understand
 that part ? if not, let me know, I'll bouce you the initial answer.
 
 > will also have to spend a some amount of time trying to decipher
 > what that string means and what they need to do for whatever they
 > want to add to it (or change in it).  At the moment, I am not
 > convinced that change is worth doing.  (I may change my mind
 > after I have some time to examine it, of course.  Right now I am
 > just explaining why this 5000 line update MUST be split apart)
 
 even if the above format string looks ugly at your eyes, it helps
 to keep the code relatively simple and smaller or you'll have to
 write down as many combinations using the old way or to write such
 piece of code which will extant too many the size of ps :
 
 if ((oflag && (posix && Mflag) || (!posix && Zflag)) ||
     (!oflag && zflag))
     parsefmt("zlabel");
 if ((jflag || uflag) && !nflag)
     parsefmt("user");
 if (((jflag || uflag) && nflag) ||
     ((lflag || sflag) && !(jflag || uflag)))
     parsefmt("uid");
 etc.
 
 > The update includes a change to greatly improve how multiple
 > output options are handled.  I like that idea a lot, but it is
 > mixed in with so many other things.  I had noticed some of the
 > same problems you noticed, and I have an update which fixes
 > some of those issues.  It looks like you have spent a lot more
 > time figuring out how the options should interact, and I think I
 
 yes, I picked up as many output of ps I could and taken the common
 denominator of all of them. I may provide you an excel sheet (almost
 up-to-date) which helps me to write down my current implementation
 of ps.
 
 > am at least going to take advantage of that by seeing if I can
 > get my update to print columns out in about the same order.  I
 > am going to do that by just comparing outputs, though, because
 > that will take me less time than trying to figure out and
 > extract the part of this that I am interested in.
 
 using the old way, you will have a lot of format string to write
 down in an inefficient way as more options will probably be added.
 
 > The patch adds a number of "posix" improvements.  It was always
 [snip]
 > how people like that.  It will be faster and easier for me to
 > finish that work, than it will be to sort out all the many
 > different issues in this one massive update.
 
 issues ?
 
 > My goal was similar to yours, but my update for it is certainly
 > much less ambitious.  Your update refers to many "posix" options.
 
 what I call "posix" is really "posix"-like, aka SystemV syntax
 vs. BSD-like syntax. most of the posix behaviours ARE SystemV
 based, not BSD based. even if there is a little common denominator.
 
 > In my case, I am working from the official released standard of
 > SingleUnixSpecification, version 3.  I do not have the latest
 
 as I am.
 
 > POSIX description of `ps', but my understanding is that SUSv3
 > is supposed to be exactly the same as POSIX.  (it would not
 > surprise me if I am wrong about that).
 
 it's mine too. that's why I clearly state "posix (hpux)" and not
 only "posix" in the following example. which stand for the
 HP-UX behaviour using the "posix syntax".
 
 > The patch includes sections like:
 > /*
 > * posix (hpux) : -C cmdlist
 > * select processes by command name.
 > * bsd : raw cpu usage instead of the average one.
 > */
 > I personally have no desire to end up with a version of `ps'
 > which implements every option known to any other operating
 > system under the sun.  My concern is that will make `ps' much
 
 I've not implemented all of them :) but the ones which, IMHO,
 are really interresting to have. in the above example, since
 I have "ps -C", I'm using it really often instead of doing
 "ps -ef | grep [x]xxx" or such construction.
 well, I exactly said the opposite of what I said above in this
 email regarding "ps xx yy zz", that is don't modify a command
 to fit your needs if it is not necessary, however, this is
 implemented in a somewhat standard way (using an option string)
 in opposition to the non-standard way "ps xx yy zz" was implemented.
 
 > larger than it needs to be, and that very few people will
 > actually benefit from it.  Furthermore, I suspect it will just
 
 not sure about that, I'm pretty sure rc.subr maintainers will
 love "ps -C command" :)
 
 > open us up to a long string of PR's where someone says "You
 > have this option from IRIX, but you have not implemented it
 > exactly the way IRIX implemented it" -- at the same time some
 > other person complains that the exact same option does not work
 > the way *solaris* implements it.  I do not think we can be all
 > things to all people, and I think it will be a big waste of
 > time for us to try.
 
 if clearly documented, I suppose this would not be a problem.
 we may be clearly say (in the BUGS section) that the non
 standard options are provided for convenience and that they
 can differ from the original implementation and that if they
 want an exact replication of such option that they goes or
 return to that original implementation. or something like
 that :)
 
 however, there is not so many "non-standard" (aka SUSv3)
 options :
 
 n/a == -C command (hpux)
     may be really usefull in scripts and even on the command line.
 -o ... == -c (solaris) / -P (solaris) / -y (solaris)
     may be simulated using -o ..., not necessarry, but convenient.
 -j == -j
     exists in almost all if not all SystemV derivated ps.
 -Z == -M (irix)
     for convenience only to match the BSD counterpart.
 -H == -L (solaris) / -m (tru64) / -T (irix)
     not my fault if there is no consensus between SystemV OSes
 -O == -O
     but may be simulated using -o, however, it does not hurt
     to provide it since the BSD flavour has it.
 -ww == -x (hpux)
     SystemV OSes has the habit to trunc the command line
 
 > What I intend to support is just two main modes.  The first
 > mode is "Whatever *we* want as options for a BSD `ps'", and the
 > second is "Whatever is described in the settled standard of SUSv3".
 > That will still be a huge step forward from where we are.  After
 > we get to that point, we can certainly look at additional ideas.
 > I actually want to add a third mode, which would be "SUSv3 plus
 > a very few safe extensions".  I imagine that could start an
 
 that was I proposed at first. since almost everybody said it would
 be too complicated to have many personalities, I merge the posix
 personality w/ what we could name the extended personality.
 
 > endless bikeshed, but I did implement `-s sidlist' (as seen in
 > solaris/aix) because I have wanted it in the past, and by golly
 > that option should be *somewhere* even if it *does* conflict
 > with NetBSD!   :-)
 
 IMHO, we could consider NetBSD -s is FreeBSD -H even if our current
 -H option differ from the NetBSD -s one. in the meanwhile, they both
 stand for "show threads".
 
 > Please note that this does not mean that I would never add more
 > options, such as the ones you have implemented.  It just means
 > that I do not believe they must be added all at once.  We can
 > split this into several updates, and commit them as time permits.
 
 see the proposed plan at the beginning of the message.
 
 > I also think it's important to ask other FreeBSD developers what
 > they want, although I fear we have already talked so much about
 > `ps' that some developers wish that I would just shut up about
 > it for a few years.
 
 I suggest to go back to -standard for futher discutions regarding ps.
 
 > Your update also improves the handing for '-t <ttylist>', and I
 > like that idea a lot.  That is only a small part of your update,
 > and I expect it would be easy for me to pull that part out and
 > commit it.  I hope to do that as soon as I get the chance.
 
 [snip -t and const]
 
 see the proposed plan at the beginning of the message.
 </second message>
 
 <third  message>
 [snip cwarnflags]
 
 just compiled w/ your extra flags w/ only one error which is :
 
 // #define EMULLEN    7    /* emul */
 
 instead of :
 
 #if 0
 #define EMULLEN    7    /* emul */
 #endif
 
 [snip]
 > My updates certainly do not do everything yours does, but then
 > yours does not fix all of the things that I wanted to fix.  So if I
 
 could you explicitly say what you wanted to fix ?
 
 [snip the wheel etc. :)]
 
 > So this is my plan.  I also plan to pull in a few things from your
 > large `ps' update, and some more of your kern-related changes.  I
 > am happy to credit you for the things I commit from your work, and
 > I did do that for the few kern-related things I already installed.
 
 thanks.
 
 > I doubt that any of this makes you feel any happier, but I felt
 > you at least deserved a more detailed answer before I decided
 > what to do with my pending patches vs your larger patch.
 
 could we find your pending patches somewhere ?
 
 > Now I just have to find the time to finish off my patches!
 > [actually, I hope to apply a few of your kern-related patches
 > first, as I expect that will make things easier for both of us]
 
 are you talking about KERN_PROC_* and/or ki_* stuffs ?
 </third message>
 
 <fourth message> 
 [snip SUSv3]
 
 the "missing" SUSv3 added options does not conflict w/ any other
 ps as far as I know except the ones which are threads related which
 does not conflicts, but which are differents. since SUSv3 and later
 only takes the least common denominator between what already exists,
 they should not conflict w/ any futher release of SUSv3.
 </fourth message>
 
 you almost said nothing regarding others pieces of code of `ps'
 other than ps.c such as keyword.c and print.c ? any thoughts ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 15 Jun 2004 15:18:43 -0400

 At 1:27 PM +0200 6/15/04, Cyrille Lefevre wrote:
 >
 >Garance wrote:
 >  > First, a very minor nit:  This PR mentions:
 >>       FYI, here are the ps sizes once compiled w/ -O
 >>       and stripped :
 >>           -current : 38048
 >>           this one : 38760
 >  > You have already corrected in later emails (one if which
 >  > ended up in the audit-trail of this PR), but I just thought
 >  > I would note that those numbers are not right.
 >
 >I am pretty sure I sent an email to correct what I said. in fact,
 >-current was compiled w/ -g and "this one"... this explain that.
 
 Yes, I am sure you did too.  However, that was not pointed out
 in the history of this PR, so I just wanted to repeat it here
 for the benefit of anyone who reads just this PR without all
 the other email that has gone back-and-forth.
 
 >  > However, the update also makes some cosmetic changes which
 >  > *add* "style errors".  Code in the base system should try to
 >  > follow the advice in 'man 9 style' as much as possible.
 >
 >as a general rune, I try to follow style(9), but style(9) is
 >somewhat large and it's not as simple to always remember what's
 >detailed there.
 
 True, but once I start committing these changes, I will be
 grilled on every single line which adds a style(9) bug.  I
 know that, because that *is* what happens when I commit my
 own changes with style(9) bugs!   :-)
 
 >  > It is possible that there is still some bug there, but I compared
 >>  the sort-result of your `ps' against what we have in 5.x-current,
 >>  and the sort-order is exactly the same in both.
 >[snip]
 >
 >as said before, I intend to import netbsd auto-field-sizing which
 >will include -k sort option since they are very close (parsefmt()
 >vs. parsesort()).
 
 That does not explain why you have to replace the present pscomp
 routine (which is what your large patch does).
 
 >  > The patch includes the parseopts routine, which includes the
 >>  scary line of:
 >>
 >>  + static char bsd_fmtstr[] = "\
 >  > +label:[0Z] user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:[02]! \
 >  > ...
 >  >
 >>  I look at that, and I simply do not like it.  I know it will take
 >>  me some time to read the code just to understand what that string
 >>  is doing.  That means any developer who needs to change that code
 >
 >don't you receive an email I sent you which may help you to understand
 >that part ? if not, let me know, I'll bouce you the initial answer.
 
 I know you described it to me in some emails, but it is still
 overly complicated (IMO).  *Every* developer who goes to add
 something to some format, or who adds a new combo-format (such
 as `-u' which selects a combination of several items) is going
 to have to stop, read this, and try to figure out how to add
 their change to this encoded string.
 
 Please remember that I also said:
 
 >  > At the moment, I am not convinced that change is worth doing.  (I
 >  > may change my mind after I have some time to examine it, of course)
 
 In particular, the part where I say "I may change my mind" after
 I have had the time to look at it closer, and to see how good (or
 how bad) my own format-cleanup will turn out.
 
 >  > It will be faster and easier for me to finish
 >  > that [Garance] work, than it will be to sort out all the many
 >  > different issues in this one massive update.
 >
 >issues ?
 
 All of the issues that I noticed while skimming the changes to ps.c
 in your 5000 line update.  You know, the issues listed in the message
 you are replying to.  The issues that I listed to explain why I can
 not simply commit this 5000 line update in one block.  Those issues.
 
 ><third  message>
 >[snip cwarnflags]
 >
 >just compiled w/ your extra flags w/ only one error which is :
 >
 >// #define EMULLEN    7    /* emul */
 >
 >instead of :
 >
 >#if 0
 >#define EMULLEN    7    /* emul */
 >#endif
 
 Huh.  I got a whole bunch of extra warnings after I fixed that line.
 I ended up compiling with no CWARNFLAGS just so I would be able to
 test your version.  I'll try this again after I get the kern-related
 changes installed.
 
 At least some of the warnings looked like they might be related to
 sections of code in `ps' that I was skipping over (and which I had
 to skip over because my system does not have the extra fields in
 kinfo_proc).  Please don't worry about this.  There is no sense
 fixing those #ifdef's when the entire issue will be fixed by simply
 committing the kern-related changes.
 
 >  > Now I just have to find the time to finish off my patches!
 >>  [actually, I hope to apply a few of your kern-related patches
 >>  first, as I expect that will make things easier for both of us]
 >
 >are you talking about KERN_PROC_* and/or ki_* stuffs ?
 
 Basically "Everything outside of bin/ps", or at least everything
 that I'm comfortable in doing.  At this point I expect to skip the
 changes which add 'u_short ki_cmask', but do most of the others.  I
 might be able to get that in this weekend, although it is true that
 I am still mainly concentrating on newsyslog at the moment.
 
 Based on what I've checked so far, the auto-align thing that you
 added isn't really correct.  It happens to work okay, but it will
 fall apart if any other variables are added (and I already have
 other variables to add).  It also broke, for instance, when I
 took out the ki_cmask variable.  I have a program which prints out
 the layout of a struct, and I'm using that to decide what the best
 order would be for the new variables.  Once I am sure I have
 something that looks good on all platforms, I should be able to
 commit many of these non-`ps' changes.
 
 I should also admit that it turned out that all my own clever
 ideas to auto-align that same field did not work out.  I have
 done various clever things in the past with combinations of
 offsetof() and sizeof().  But I can not use offsetof() in this
 case because I would need to use it in the middle of defining
 the struct.  So, I will have to go with some low-tech way to
 handle the alignment.  Bah.
 
 [I was also apparently having flashbacks to my days of
 programming in assembler, and C just isn't quite as flexible
 as IBM's asmh assembler...]
 
 >you almost said nothing regarding others pieces of code of `ps'
 >other than ps.c such as keyword.c and print.c ? any thoughts ?
 
 I have not looked at them.  It took me most of the weekend just
 to skim through the updates to ps.c, and to decide what order I
 was going to do things in.  Now that I have decided, I am just
 going to pick away at those things.  I think we'll both feel
 better if we start to see some of these things getting committed,
 instead of spending all our time just writing each other over
 the parts which we did not instantly agree upon.
 
 I also concentrated on ps.c because that's the file that I have
 worked on the most, and that I am the most familiar with.  It is
 also where the vast majority of my own pending-changes are, so
 it is where your updates will conflict with mine.  "Conflict" in
 the sense that we're changing the same lines of code -- even if
 we happen to be changing them with similar goals in mind.  I have
 very few pending changes to the other files under src/bin/ps.  In
 fact, at the moment I can only think of one that I want to commit,
 and that's a one-line change.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 16 Jun 2004 01:41:08 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 1:27 PM +0200 6/15/04, Cyrille Lefevre wrote:
 > >Garance wrote:
 [snip sizeof(/bin/ps) and style(9)]
 
 ok
 
 [snip] 
 > That does not explain why you have to replace the present pscomp
 > routine (which is what your large patch does).
 
 as you said, just to shrink some lines in the resultant code.
 
 [snip fmtstr]
 
 nothing more to say for instance.
 
 [snip issues]
 
 ok, for me, an issue is something which doesn't work as expected...
 at run time.
 
 [snip cwarnflags]
 
 ok, as you said, your are probably missing kernel related stuffs or
 whatever. I tried again w/o any warning or error.
 
 > >  > Now I just have to find the time to finish off my patches!
 > >>  [actually, I hope to apply a few of your kern-related patches
 > >>  first, as I expect that will make things easier for both of us]
 > >
 > >are you talking about KERN_PROC_* and/or ki_* stuffs ?
 > 
 > Basically "Everything outside of bin/ps", or at least everything
 > that I'm comfortable in doing.  At this point I expect to skip the
 > changes which add 'u_short ki_cmask', but do most of the others.  I
 > might be able to get that in this weekend, although it is true that
 > I am still mainly concentrating on newsyslog at the moment.
 
 what is the problem w/ ki_cmask ? (PS : it helps for alignment :)
 
 > Based on what I've checked so far, the auto-align thing that you
 > added isn't really correct.  It happens to work okay, but it will
 > fall apart if any other variables are added (and I already have
 > other variables to add).  It also broke, for instance, when I
 > took out the ki_cmask variable.  I have a program which prints out
 
 if you take out ki_cmask, you have to change :
 
     ki_align[(sizeof(long)!=sizeof(int))*2];
 to
     ki_align[(sizeof(long)!=sizeof(int))];
 and to augment ki_spare by 1 (14 -> 15).
 
 or to add an "int _unused;" around ki_cursig.
 
 > the layout of a struct, and I'm using that to decide what the best
 > order would be for the new variables.  Once I am sure I have
 > something that looks good on all platforms, I should be able to
 > commit many of these non-`ps' changes.
 
 the problem is struct timeval which has a different size per arch :(
 I'm not sure there is something to do, here until
 sizeof(struct timeval) has the same size everywhere...
 
 > I should also admit that it turned out that all my own clever
 > ideas to auto-align that same field did not work out.  I have
 > done various clever things in the past with combinations of
 > offsetof() and sizeof().  But I can not use offsetof() in this
 > case because I would need to use it in the middle of defining
 > the struct.  So, I will have to go with some low-tech way to
 > handle the alignment.  Bah.
 
 I've also tried many things w/o success except the provided one :(
 
 > >you almost said nothing regarding others pieces of code of `ps'
 > >other than ps.c such as keyword.c and print.c ? any thoughts ?
 > 
 > I have not looked at them.  It took me most of the weekend just
 > to skim through the updates to ps.c, and to decide what order I
 > was going to do things in.  Now that I have decided, I am just
 > going to pick away at those things.  I think we'll both feel
 > better if we start to see some of these things getting committed,
 > instead of spending all our time just writing each other over
 > the parts which we did not instantly agree upon.
 
 I'm don't agree w/ you about committing stuffs w/o knowing where
 we go and in what order. maybe it's clear for you, but not for me.
 as I told you, I can provide you the updates you want and probably
 the way you want. the problem is that you didn't say much about
 what your pending updates are and in which way they conflicts w/
 mine ?
 
 in other words, I propose you the beginning of a plan, well, it's
 not finished, but that a beginning. it is the base of all well
 done projects to know the way to go.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 15 Jun 2004 20:30:10 -0400

 At 1:41 AM +0200 6/16/04, Cyrille Lefevre wrote:
 >
 >>  I should also admit that it turned out that all my own clever
 >>  ideas to auto-align that same field did not work out.  I have
 >>  done various clever things in the past with combinations of
 >>  offsetof() and sizeof().  But I can not use offsetof() in this
 >>  case because I would need to use it in the middle of defining
 >>  the struct.  So, I will have to go with some low-tech way to
 >>  handle the alignment.  Bah.
 >
 >I've also tried many things w/o success except the provided one :(
 
 Well, I already have a workable solution figured out.  It is not
 automatic though.  I took the mundane way out.  Right now I am
 just waiting for someone to test it for me on PPC, to make sure
 I have not ruined the layout for that platform.  I have already
 checked the new layout on all the other platforms.  Hmm, well,
 actually the AMD64 machine crashed right in the middle of me
 testing it, so I guess I will have to repeat that check for that
 platform after someone reboots the AMD64 test machine.
 
 I should buy one of those machines, too, one of these days...
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 02:26:11 -0400

 In the update to kern_proc.c, you have a reference to 'timeradd'.
 That is not usually defined in this file.  How does it end up
 being defined in your system?
 
 For the moment, for my testing I'm just copying it from sys/time.h.
 I can see the bug it is fixing, but I might decide to undo that
 change in kern_proc.c and do it later as a separate update.  That
 is probably what I should do...
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 03:54:07 -0400

 Also, I think I have all the cursig updates installed in my test
 system.  I recompiled your `ps' with the appropriate options such
 that `-O cursig' is available.  In my testing, `ps -ax -o cursig'
 seems to always find a value of zero for all processes on my
 system.  Is that likely to be correct?  Or have I probably messed
 up something?
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 12:12:23 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Also, I think I have all the cursig updates installed in my test
 > system.  I recompiled your `ps' with the appropriate options such
 > that `-O cursig' is available.  In my testing, `ps -ax -o cursig'
 > seems to always find a value of zero for all processes on my
 > system.  Is that likely to be correct?  Or have I probably messed
 > up something?
 
 
 I suppose this is correct since it will be very hard to catch this
 event between the time where the signal is posted, and the time it
 is handled. on tru64 too, I never see other values than zero.
 maybe you could ask a kernel guru about that ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 15:41:02 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > In the update to kern_proc.c, you have a reference to 'timeradd'.
 > That is not usually defined in this file.  How does it end up
 > being defined in your system?
 
 I've just seen that before to read this message :)
 while restoring the original ki_childtime, I added this timeradd().
 unfortunatelly, timeradd() is not defined in the kernel space !
 strange, since usyally, it is often the opposite to have things
 defined the the kernel space and not in the user space...
 
 sorry, to not have build a new kernel to validate this change, but
 I have a really slow machine (P200) and it takes me 1 to 3 days to
 cvsup, cvs update, and make buildworld buildkernel...
 
 > For the moment, for my testing I'm just copying it from sys/time.h.
 > I can see the bug it is fixing, but I might decide to undo that
 > change in kern_proc.c and do it later as a separate update.  That
 > is probably what I should do...
 
 for instance, I've I kept the original code plus the fix as :
 
 <original code>
                 kp->ki_childtime.tv_sec = p->p_stats->p_cru.ru_utime.tv_sec +
                     p->p_stats->p_cru.ru_stime.tv_sec;
                 kp->ki_childtime.tv_usec = p->p_stats->p_cru.ru_utime.tv_usec +
                     p->p_stats->p_cru.ru_stime.tv_usec;
 </original code>
 <fix>
                 if (kp->ki_childtime.tv_usec >= 1000000) {
                         kp->ki_childtime.tv_sec++;
                         kp->ki_childtime.tv_usec -= 1000000;
                 }
 </fix>
 
 I'll ask -current why timeradd() and co are hidden from the kernel space...
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 11:39:02 -0400

 At 12:12 PM +0200 6/17/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  Also, I think I have all the cursig updates installed in my test
 >>  system.  I recompiled your `ps' with the appropriate options such
 >>  that `-O cursig' is available.  In my testing, `ps -ax -o cursig'
 >>  seems to always find a value of zero for all processes on my
 >>  system.  Is that likely to be correct?  Or have I probably messed
 >  > up something?
 >
 >I suppose this is correct since it will be very hard to catch this
 >event between the time where the signal is posted, and the time it
 >is handled. on tru64 too, I never see other values than zero.
 >maybe you could ask a kernel guru about that ?
 
 I am not sure that there is much to gain in adding this option if
 the value is always zero.  More importantly for me, it makes it
 hard to know if the code is even returning the correct value.
 Right now I am running a `ps' loop on my dual-processor system to
 see if it ever comes up a non-zero value for cursig (waiting a few
 seconds between each `ps', of course...).  If none of them show up
 by Friday evening, then I will remove the cursig changes.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 11:43:49 -0400

 At 3:41 PM +0200 6/17/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  In the update to kern_proc.c, you have a reference to 'timeradd'.
 >>  That is not usually defined in this file.  How does it end up
 >>  being defined in your system?
 >
 >I've just seen that before to read this message :)
 >while restoring the original ki_childtime, I added this timeradd().
 >unfortunatelly, timeradd() is not defined in the kernel space !
 >strange, since usually, it is often the opposite to have things
 >defined the the kernel space and not in the user space...
 
 Well, I am comfortable with simply copying the timeradd macro
 from the include file to kern_proc.c.  If someone doesn't like
 that, I am sure they'll tell me a better way of doing it!
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 13:10:05 -0400

 For now I am also skipping the maxrss changes.  I would need to
 do more investigation of that change before I would feel
 comfortable with it.  That change may be perfectly fine, I am
 just saying that I don't know enough to know if it is.
 
 In particular, I am not sure if the variable added to kinfo_proc
 is supposed to be equivalent to OpenBSD's p_uru_maxrss field in
 struct kinfo_proc2, or the p_rlim_rss_cur field.  Their `ps'
 uses the p_rlim_rss_cur field to implement maxrss.  If the
 variable added by the patch is indeed the same "soft-limit for
 RSS" value, then I would want it to have a name such as
 ki_rlim_rss_cur instead of ki_maxrss.  And if it is not the
 same value, well, then our keyword would not really be the same
 as theirs.
 
 I have enough going on with the other changes I hope to commit
 this weekend, so I intend to let this one wait until some later
 commit.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 15:08:03 -0400

 Hmm.  Well I probably won't get this done this weekend.  PHK just
 committed the second half of the big dev_t cleanup.  To do that,
 he obviously needed to modify all the same files that my upcoming
 commit would modify...  This is a cleanup that "we all" (the
 developers) had agreed he should get done before 5.3-release.
 
 I might be able to split out the tty-related changes, and at least
 install the changes for KERN_PROC_GID, ki_emul, ki_childstime, and
 ki_childutime.
 
 In a previous message you wrote:
 >  Sorry, to not have build a new kernel to validate this change,
 >  but I have a really slow machine (P200) and it takes me 1 to 3
 >  days to cvsup, cvs update, and make buildworld buildkernel...
 
 That's okay.  My dual-athlon is much faster than that, but I
 also want to compile and install this on my Ultra-10 sparc.
 *That* is usually a 2-day process, so I know how it feels to
 work on system-changes on a slow machine!
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 21:42:29 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > For now I am also skipping the maxrss changes.  I would need to
 > do more investigation of that change before I would feel
 > comfortable with it.  That change may be perfectly fine, I am
 > just saying that I don't know enough to know if it is.
 > 
 > In particular, I am not sure if the variable added to kinfo_proc
 > is supposed to be equivalent to OpenBSD's p_uru_maxrss field in
 > struct kinfo_proc2, or the p_rlim_rss_cur field.  Their `ps'
 > uses the p_rlim_rss_cur field to implement maxrss.  If the
 > variable added by the patch is indeed the same "soft-limit for
 > RSS" value, then I would want it to have a name such as
 > ki_rlim_rss_cur instead of ki_maxrss.  And if it is not the
 > same value, well, then our keyword would not really be the same
 > as theirs.
 
 IMHO, rlim_rss_cur is not accurate, since maxrss is the minimum
 value of rlim_rss_cur (soft) or rlim_rss_max (hard), not only
 rlim_rss_cur.
 
 I name this field ki_maxrss for historical reasons, p_maxrss (proc)
 existed for years in many previous releases of different unices.
 
 > I have enough going on with the other changes I hope to commit
 > this weekend, so I intend to let this one wait until some later
 > commit.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 21:43:50 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 12:12 PM +0200 6/17/04, Cyrille Lefevre wrote:
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >>  Also, I think I have all the cursig updates installed in my test
 > >>  system.  I recompiled your `ps' with the appropriate options such
 > >>  that `-O cursig' is available.  In my testing, `ps -ax -o cursig'
 > >>  seems to always find a value of zero for all processes on my
 > >>  system.  Is that likely to be correct?  Or have I probably messed
 > >  > up something?
 > >
 > >I suppose this is correct since it will be very hard to catch this
 > >event between the time where the signal is posted, and the time it
 > >is handled. on tru64 too, I never see other values than zero.
 > >maybe you could ask a kernel guru about that ?
 > 
 > I am not sure that there is much to gain in adding this option if
 > the value is always zero.  More importantly for me, it makes it
 > hard to know if the code is even returning the correct value.
 > Right now I am running a `ps' loop on my dual-processor system to
 > see if it ever comes up a non-zero value for cursig (waiting a few
 > seconds between each `ps', of course...).  If none of them show up
 > by Friday evening, then I will remove the cursig changes.
 
 
 I've tried the following program for a few minutes w/o success :
 
 cat << EOF > c.c
 #include <signal.h>
 void trap (int s) { sleep(1); }
 int main () {
         pid_t pid = getpid();
         signal(SIGUSR1, trap);
         for (;;) kill(pid, SIGUSR1);
 }
 EOF
 make c
 ./c&
 while :; do ps -o cursig= -p $!; done
 
 did you ask to some kernel guru about that ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 21:55:17 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Hmm.  Well I probably won't get this done this weekend.  PHK just
 > committed the second half of the big dev_t cleanup.  To do that,
 > he obviously needed to modify all the same files that my upcoming
 > commit would modify...  This is a cleanup that "we all" (the
 > developers) had agreed he should get done before 5.3-release.
 
 take care about this change, since ps deal w/ dev_t and udev_t.
 do you remember the fixes I sent to you about that ?
 
 > I might be able to split out the tty-related changes, and at least
 > install the changes for KERN_PROC_GID, ki_emul, ki_childstime, and
 > ki_childutime.
 
 I'm currently adding thread stuff in there to implement lwp (td_tid)
 and nlwp. I'm testing the difference of kg_numthreads, kg_kses and
 counting myself the number of threads in the FOREACH_THREAD_IN_PROC(p, td0)
 loop.
 
 > In a previous message you wrote:
 > >  Sorry, to not have build a new kernel to validate this change,
 > >  but I have a really slow machine (P200) and it takes me 1 to 3
 > >  days to cvsup, cvs update, and make buildworld buildkernel...
 > 
 > That's okay.  My dual-athlon is much faster than that, but I
 > also want to compile and install this on my Ultra-10 sparc.
 > *That* is usually a 2-day process, so I know how it feels to
 > work on system-changes on a slow machine!
 
 pfff, an Ultra-10 sparc is far more powerfull than a P200 :)
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 18:22:00 -0400

 Well, for the last seven hours I have been running a while-loop
 which does a:
      ps-cyr -ax -o cursig,pid,stat,time,command
 every seven seconds, while I have been stress-testing the machine.
 I have done a number of cvsup's, and buildworlds, and running
 various servers.  I am also running two copies of a folding-at-home
 client, which keeps the CPU usage at 100%.  So far I have seen
 exactly one case where cursig was not zero:
 
 17:27:21  -    Found non-zero cursig!
    CURSIG   PID STAT      TIME COMMAND
         b   808 RN+    0:01.03 ./FahCore_65.exe -dir work/ -suffix 08 -lifeline
 
 I'm not sure what 'b' is supposed to mean there...
 
 So right now I am rebuilding the changes I had (after updating
 them to match PHK's big commit), except that I removed the tty
 changes and the cursig changes.
 
 I have not asked anyone about cursig.  I have nothing against
 the idea if I was confident it was working right, and that it
 was showing useful information.  But I am not interested enough
 to spend more time on it, given the results I have seen so far.
 [As I mentioned in an earlier message, I really have no desire
 to become a kernel programmer...]
 
 I still like the tty changes, but if I try to understand what
 has changed there, I will certainly not get anything committed
 this weekend.  It's probably better to break that out into a
 separate update, anyway.
 
 >  > That's okay.  My dual-athlon is much faster than that, but I
 >>  also want to compile and install this on my Ultra-10 sparc.
 >>  *That* is usually a 2-day process, so I know how it feels to
 >>  work on system-changes on a slow machine!
 >
 >pfff, an Ultra-10 sparc is far more powerfull than a P200 :)
 
 The CPU is, but the disk-system is *awfully* slow.  It really
 does take me more than 7 hours just to do a buildworld...  Add
 in the time for cvsup, buildkernel, installkernel, and I never
 get a complete "buildworld cycle" completed in a single day. I
 usually get it done in two days, but occasionally it takes three
 (particularly if there are any compile-time errors in what I am
 testing...).
 
 At 9:55 PM +0200 6/17/04, Cyrille Lefevre wrote:
 >  > PHK just committed the second half of the big dev_t cleanup.
 >
 >take care about this change, since ps deal w/ dev_t and udev_t.
 >do you remember the fixes I sent to you about that ?
 
 My solution is to skip those updates for now...  :-)
 
 >  > I might be able to split out the tty-related changes, and
 >  > at least install the changes for KERN_PROC_GID, ...etc...
 >
 >I'm currently adding thread stuff in there to implement lwp
 >(td_tid) and nlwp. I'm testing the difference of kg_numthreads,
 >kg_kses and counting myself the number of threads in the
 >FOREACH_THREAD_IN_PROC(p, td0) loop.
 
 Hmm.  Well, do not race ahead on my account.  It is very likely
 that after this commit, I will not be looking to do more
 kern-related commits for awhile.  Probably not for a few weeks.
 Instead, I'll turn my attention towards some of the pending
 updates to `ps' itself.  (and MFC'ing my changes to newsyslog)
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 01:12:14 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Well, for the last seven hours I have been running a while-loop
 > which does a:
 >      ps-cyr -ax -o cursig,pid,stat,time,command
 > every seven seconds, while I have been stress-testing the machine.
 > I have done a number of cvsup's, and buildworlds, and running
 > various servers.  I am also running two copies of a folding-at-home
 > client, which keeps the CPU usage at 100%.  So far I have seen
 > exactly one case where cursig was not zero:
 >
 > 17:27:21  -    Found non-zero cursig!
 >    CURSIG   PID STAT      TIME COMMAND
 >         b   808 RN+    0:01.03 ./FahCore_65.exe -dir work/ -suffix
 08 -lifeline
 >
 > I'm not sure what 'b' is supposed to mean there...
 
 strange, since %ld is used there ! I'll try for a long time run on my side.
 
 > So right now I am rebuilding the changes I had (after updating
 > them to match PHK's big commit), except that I removed the tty
 > changes and the cursig changes.
 
 does ps -t $(tty) still works ?
 
 [snip]
 > I still like the tty changes, but if I try to understand what
 > has changed there, I will certainly not get anything committed
 > this weekend.  It's probably better to break that out into a
 > separate update, anyway.
 
 I'll cvsup, etc. again to get the last changes. so, be patient :)
 
 [snip u10]
 > The CPU is, but the disk-system is *awfully* slow.  It really
 
 forgot that newer workstation don't have SCSI drives...
 which makes them sucks :(
 
 > At 9:55 PM +0200 6/17/04, Cyrille Lefevre wrote:
 [snip]
 > >I'm currently adding thread stuff in there to implement lwp
 > >(td_tid) and nlwp. I'm testing the difference of kg_numthreads,
 > >kg_kses and counting myself the number of threads in the
 > >FOREACH_THREAD_IN_PROC(p, td0) loop.
 >
 > Hmm.  Well, do not race ahead on my account.  It is very likely
 > that after this commit, I will not be looking to do more
 > kern-related commits for awhile.  Probably not for a few weeks.
 
 frankly, these changes will be only 2 lines in kern_proc.c and
 2 lines in user.h w/o any danger.
 
 > Instead, I'll turn my attention towards some of the pending
 > updates to `ps' itself.  (and MFC'ing my changes to newsyslog)
 
 good luck :)
 
 PS : just submitted, standalone repeat(1) outside of csh(1).
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 01:50:55 +0200

 "Cyrille Lefevre" <cyrille.lefevre@laposte.net> wrote:
 [snip]
 > for instance, I've I kept the original code plus the fix as :
 >
 > <original code>
 >                 kp->ki_childtime.tv_sec = p->p_stats->p_cru.ru_utime.tv_sec +
 >                     p->p_stats->p_cru.ru_stime.tv_sec;
 >                 kp->ki_childtime.tv_usec = p->p_stats->p_cru.ru_utime.tv_usec
 +
 >                     p->p_stats->p_cru.ru_stime.tv_usec;
 > </original code>
 > <fix>
 >                 if (kp->ki_childtime.tv_usec >= 1000000) {
 >                         kp->ki_childtime.tv_sec++;
 >                         kp->ki_childtime.tv_usec -= 1000000;
 >                 }
 > </fix>
 >
 > I'll ask -current why timeradd() and co are hidden from the kernel space...
 
 short answer from Bruce Evans, use timevaladd() and co...
 so, the above code may be replaced w/ :
 
 #include <sys/time.h>
 ...
                 timevalclear(&kp->ki_childtime);
                 timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_utime);
                 timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_stime);
 
 compiled in my new kernel w/o errors but not tested yet (I'll reboot tomorrow
 only).
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 17 Jun 2004 21:13:03 -0400

 At 1:12 AM +0200 6/18/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >  > So far I have seen exactly one case where cursig was not zero:
 >  >
 >>  17:27:21  -    Found non-zero cursig!
 >>     CURSIG   PID STAT      TIME COMMAND
 >>          b   808 RN+    0:01.03 ./FahCore_65.exe -dir work/ -suffix
 >08 -lifeline
 >>
 >>  I'm not sure what 'b' is supposed to mean there...
 >
 >strange, since %ld is used there ! I'll try for a long time run
 >on my side.
 
 Yeah, I kept looking at that and thinking "that must be a typo",
 but the window was still open that I did it from, and it was
 definitely a 'b'.  That's actually a copy&paste from the window,
 but I still feel it must be a typo!
 
 The `ps-cyr' that I was testing with is just your 5000 line
 update applied to the latest `ps'.  That helps me test the
 system changes that I have put together.
 
 >  > So right now I am rebuilding the changes I had (after updating
 >>  them to match PHK's big commit), except that I removed the tty
 >>  changes and the cursig changes.
 >
 >does ps -t $(tty) still works ?
 
 I do not understand what you mean by that.  That was already
 working.  That is not related to any of your changes.  The
 present freebsd `ps' already understands:
       ps -t /dev/ttyp0
 and  ps -t p0
 what it does not handle is:  ps -t ttyp0
 
 That third option does with my copy of your `ps' running on a
 system with the updates that I plan to commit.  That does not
 depend on any of the kern-related updates for tty handling (but
 it *does* depend on updates to `ps' which I probably won't get
 to this weekend).  The newer options that will *not* work are:
       ps -t -
 and  ps -t ?
 because those depend on kern-related updates that I will not be
 committing this weekend.
 
 [next message]
 >The short answer from Bruce Evans, use timevaladd() and co...
 >so, the above code may be replaced w/ :
 >
 >#include <sys/time.h>
 >...
 >        timevalclear(&kp->ki_childtime);
 >        timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_utime);
 >        timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_stime);
 
 Well, that is doing more work than we need to do.  Now that we know
 what routine to use, we can see it being used just a few lines
 earlier:
 
 	kp->ki_start = p->p_stats->p_start;
 	timevaladd(&kp->ki_start, &boottime);
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 14:35:18 -0400

 >  IMHO, rlim_rss_cur is not accurate, since maxrss is the minimum
 >  value of rlim_rss_cur (soft) or rlim_rss_max (hard), not only
 >  rlim_rss_cur.
 >
 >  I name this field ki_maxrss for historical reasons,
 >  p_maxrss (proc) existed for years in many previous releases of
 >  different unices.
 
 Well, my gut feeling is that maybe we should return the value of
 rlim_rss_cur, and not the min of the two values.  Is the rlim_rss_max
 value a hard limit which is the same for all processes?  If so, then
 we do not really need it in the `p(rocess)s(tatus)' command.  And if
 the value is different for different processes, then we should return
 both values, and let the caller decide which one they want.  (It seems
 to me that this is similar to returning childstime and childutime as
 separate fields, instead of adding them together to return childtime).
 
 But the main problem here is that I really have no strong opinion
 on which of these things is the RightThing(TM) to do.  Seems to me
 that for some of these questions (like maxrss), someone who knows
 more about these issues should be handling this.  I feel like I
 am just getting in the way, because I have no clear idea of what
 is and is not reasonable...
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 15:48:14 -0400

 When compiling these libkvm, I notice the warning:
 
 .../libkvm/kvm_proc.c: In function `kvm_proclist':
 .../libkvm/kvm_proc.c:267: warning: assignment makes integer
                                   from pointer without a cast
 
 Line 267 is:
 
 	kp->ki_tdev = tty.t_dev;	/* XXX: wrong */
 
 That is not a line that we have changed.  It is just that I
 noticed that warning while compiling.  It might be nice to
 find out what the issue is there, and fix it (particularly
 since someone left behind that comment saying that the line
 is wrong...).
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 18:05:22 -0400

 Another minor observation.  Whenever I try:
 
 ps-cyr -ax -O usertime,systime | grep -v '  *0:00.00   0:00.00 *'
 
 It seems the only non-zero process which comes up is the bash
 shell that typed in the command.  If I add in the -S, then I
 will see a lot more non-zero processes.  I have not looked into
 it, so maybe that is perfectly reasonable.  Just thought I'd
 mention it.  (again, I have not looked all that closely at the
 `ps' changes, I just applied the big update to it so I have it
 for testing).
 
 (I expect the behavior *with* -S is fine, I am just curious
 about the behavior without -S.  The changes to the man page
 did not seem to describe what these two options are supposed
 to show...)
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 02:44:35 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >  IMHO, rlim_rss_cur is not accurate, since maxrss is the minimum
 > >  value of rlim_rss_cur (soft) or rlim_rss_max (hard), not only
 > >  rlim_rss_cur.
 > >
 > >  I name this field ki_maxrss for historical reasons,
 > >  p_maxrss (proc) existed for years in many previous releases of
 > >  different unices.
 > 
 > Well, my gut feeling is that maybe we should return the value of
 > rlim_rss_cur, and not the min of the two values.  Is the rlim_rss_max
 > value a hard limit which is the same for all processes?  If so, then
 > we do not really need it in the `p(rocess)s(tatus)' command.  And if
 > the value is different for different processes, then we should return
 > both values, and let the caller decide which one they want.  (It seems
 > to me that this is similar to returning childstime and childutime as
 > separate fields, instead of adding them together to return childtime).
 
 for instance, I just add variables required by keywords, ki_childstime and
 ki_childutime are required by systime and usertime, and ki_maxrss by maxrss.
 so, there is no need for both ki_rlim_rss_cur and ki_rlim_rss_cur, but only
 for one of them.
 
 PS : all the work I've done is based of ancient and recent unices (the ones
 available at minnie.tuhs.org) . I've extracted all of them to see what they
 do (not only ps related stuffs :) and they take 3.8G of my poor disk space
 (4*4.2G + 1.8 for /).
 
 > But the main problem here is that I really have no strong opinion
 > on which of these things is the RightThing(TM) to do.  Seems to me
 > that for some of these questions (like maxrss), someone who knows
 > more about these issues should be handling this.  I feel like I
 > am just getting in the way, because I have no clear idea of what
 > is and is not reasonable...
 
 I don't invent qmin(rsslim.rlim_cur, rsslim.rlim_max), it cames from
 line 1553 in sys/vm/vm_pageout.c, so, I suppose there is a reason on
 the use of qmin() and not only rsslim.rlim_cur, which in turn could
 not be greater then rsslim.rlim_cur (see kern_setrlimit), but who
 says ? :).
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 02:53:14 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > When compiling these libkvm, I notice the warning:
 > 
 > .../libkvm/kvm_proc.c: In function `kvm_proclist':
 > .../libkvm/kvm_proc.c:267: warning: assignment makes integer
 >                                   from pointer without a cast
 > 
 > Line 267 is:
 > 
 > kp->ki_tdev = tty.t_dev; /* XXX: wrong */
 > 
 > That is not a line that we have changed.  It is just that I
 > noticed that warning while compiling.  It might be nice to
 > find out what the issue is there, and fix it (particularly
 > since someone left behind that comment saying that the line
 > is wrong...).
 
 
 I fixed that in the last kernel patch I sent you, here is my comment :
 
 lib/libkvm/kvm_proc.c :
 ...
 ki_tdev was not filled the right way -- fixed.
 (dev2udev() taken from sys/kern/kern_conf.c)
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 03:09:47 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Another minor observation.  Whenever I try:
 > 
 > ps-cyr -ax -O usertime,systime | grep -v '  *0:00.00   0:00.00 *'
 > 
 > It seems the only non-zero process which comes up is the bash
 > shell that typed in the command.  If I add in the -S, then I
 
 you have rebooted too recently. you can also observe this problem
 with the time keyword which is the cumulative value of systime and
 usertime.
 
 > will see a lot more non-zero processes.  I have not looked into
 > it, so maybe that is perfectly reasonable.  Just thought I'd
 > mention it.  (again, I have not looked all that closely at the
 > `ps' changes, I just applied the big update to it so I have it
 > for testing).
 > 
 > (I expect the behavior *with* -S is fine, I am just curious
 > about the behavior without -S.  The changes to the man page
 > did not seem to describe what these two options are supposed
 > to show...)
 
 as told before, I've not updated the manual page yet, because
 I did not want to do unnecessary work here before to know what
 will be included in the newer ps. the problem is, if the posix
 syntax included later, how to include it in the manual page,
 the tru64 way ? also, is it possible to use existing sentences
 from other manual pages ? specificaly, the susv3 one since I
 suppose the others (tru64, etc.) are protected by their copyright ?
 at last, I'm not a native english, so, I suppose that my written
 english is not so good for a manual as you probably read it :)
 however, I've all the manual pages merged as a big one under my
 hand and I can provide you some updates if needed.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 18 Jun 2004 22:49:37 -0400

 At 2:53 AM +0200 6/19/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  When compiling these libkvm, I notice the warning:
 >>
 >>  .../libkvm/kvm_proc.c: In function `kvm_proclist':
 >>  .../libkvm/kvm_proc.c:267: warning: assignment makes integer
 >>                                    from pointer without a cast
 >>
 >  > Line 267 is:
 >  >
 >>  kp->ki_tdev = tty.t_dev; /* XXX: wrong */
 >>
 >>  That is not a line that we have changed.  It is just that I
 >  > noticed that warning while compiling.
 >
 >I fixed that in the last kernel patch I sent you, here is my
 >comment :
 >
 >lib/libkvm/kvm_proc.c :
 >...
 >ki_tdev was not filled the right way -- fixed.
 >(dev2udev() taken from sys/kern/kern_conf.c)
 
 Oh.  I must have removed that fix when removing all the other tty
 changes.  I *did* think it was rather odd that I did notice the
 warning when I built it this time, but I had not noticed it in
 any of my previous builds...
 
 We can commit that fix in a later update.  Thanks!
 
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  Another minor observation.  Whenever I try:
 >>
 >>  ps-cyr -ax -O usertime,systime | grep -v '  *0:00.00   0:00.00 *'
 >>
 >>  It seems the only non-zero process which comes up is the bash
 >>  shell that typed in the command.  If I add in the -S, then I
 >
 >you have rebooted too recently. you can also observe this problem
 >with the time keyword which is the cumulative value of systime and
 >usertime.
 
 I rebooted 1 day, 45 mins ago.  And I have some processes running
 for folding-at-home (distributed-computing project).  If I move
 the TIME column over, I see those two processes as:
 
    PID   USRTIME   SYSTIME      TIME TT  STAT COMMAND
   1048   0:00.00   0:00.00 1457:22.91 p2  RN+  ./FahCore_65.exe -dir 
 work/ -suffi
   1056   0:00.00   0:00.00 1457:06.96 p3  ON+  ./FahCore_65.exe -dir 
 work/ -suffi
 
 I assumed that we expect TIME==USRTIME+SYSTIME.  Am I right that
 it should be?  And then `-S' would just increase all three of
 those values by the amount of time used by any children processes
 which have ended, right?  Perhaps I have deleted some other line
 that I should not have deleted...
 
 >  > (I expect the behavior *with* -S is fine, I am just curious
 >>  about the behavior without -S.  The changes to the man page
 >>  did not seem to describe what these two options are supposed
 >>  to show...)
 >
 >as told before, I've not updated the manual page yet, because
 >I did not want to do unnecessary work here before to know what
 >will be included in the newer ps.
 
 That is the right thing to do.  My comment was not meant as a
 complaint.  Sorry if it sounded that way.  Really I am just
 asking if the behavior that I am seeing is the behavior that
 you see on your system.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 11:26:55 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 2:53 AM +0200 6/19/04, Cyrille Lefevre wrote:
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 [snip dev2udev]
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >>  Another minor observation.  Whenever I try:
 > >>
 > >>  ps-cyr -ax -O usertime,systime | grep -v '  *0:00.00   0:00.00 *'
 > >>
 > >>  It seems the only non-zero process which comes up is the bash
 > >>  shell that typed in the command.  If I add in the -S, then I
 > >
 > >you have rebooted too recently. you can also observe this problem
 > >with the time keyword which is the cumulative value of systime and
 > >usertime.
 > 
 > I rebooted 1 day, 45 mins ago.  And I have some processes running
 > for folding-at-home (distributed-computing project).  If I move
 > the TIME column over, I see those two processes as:
 > 
 >    PID   USRTIME   SYSTIME      TIME TT  STAT COMMAND
 >   1048   0:00.00   0:00.00 1457:22.91 p2  RN+  ./FahCore_65.exe -dir 
 > work/ -suffi
 >   1056   0:00.00   0:00.00 1457:06.96 p3  ON+  ./FahCore_65.exe -dir 
 > work/ -suffi
 > 
 > I assumed that we expect TIME==USRTIME+SYSTIME.  Am I right that
 > it should be?  And then `-S' would just increase all three of
 > those values by the amount of time used by any children processes
 > which have ended, right?  Perhaps I have deleted some other line
 > that I should not have deleted...
 
 well, I also thought usertime+systime==time, but I see on my system
 too that is not always true ! 
 
 $ bps -ax -O usertime,systime
   PID   USRTIME   SYSTIME TT  STAT      TIME COMMAND
 68196   0:44.55   0:48.37 ??  Ss     1:32.93 /usr/sbin/named -u bind
 88810   0:04.71   0:30.75 p0  Ss     0:35.48 -ksh (ksh)
 ...
 (right, u+s==t)
 
 $ bps -ax -SO usertime,systime
   PID   USRTIME   SYSTIME TT  STAT      TIME COMMAND
  1234   0:00.00  53:20.09 ??  Ss    53:41.66 sendmail: accepting connections (s
 14861   0:00.00  44:16.24 ??  Rs    75:52.18 /usr/local/sbin/dovecot
 33469   0:00.00   0:00.16 ??  Rs   128:42.64 /usr/local/sbin/snmptrapd -a -Ls 6
 75593   0:00.00   9:23.73 ??  Ss    13:37.29 /sbin/dhclient -1 -q xl0
 ...
 94163   0:00.00   0:00.00 ??  S      9:48.27 dovecot-auth
 13157   0:00.00   0:00.00 ??  Ss     3:51.71 /usr/sbin/watchdogd
 37063   0:00.00   0:00.00 ??  Ss     1:16.24 /usr/sbin/syslogd -vv
 ...
 (wrong, not all u+s==t !)
 
 I'll try to understand why if possible, see the behaviour under tru64
 and ask the -hacker (and/or -current) ml about that.
 
 [snip man]
 
 I didn't take your comment as a complaint :)
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 12:59:58 -0400

 Well, I committed some of the kern-related changes.  Bruce has
 a few follow-on ideas though, so I might be doing something
 different for ki_childstime and ki_childutime.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 21:44:45 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > Well, I committed some of the kern-related changes.  Bruce has
 > a few follow-on ideas though, so I might be doing something
 > different for ki_childstime and ki_childutime.
 
 
 I'll try the following code :
 
         if ((p->p_sflag & PS_INMEM) && p->p_stats) {
                 struct timeval ut, st;
 
                 kp->ki_start = p->p_stats->p_start;
                 timevaladd(&kp->ki_start, &boottime);
                 kp->ki_rusage = p->p_stats->p_ru;
                 calcru(p, &ut, &st, NULL);
                 kp->ki_childtime = ut;
                 timevaladd(&kp->ki_childtime, &st);
 #ifdef PROC_CHILDTIMES
                 kp->ki_childutime = ut;
                 kp->ki_childstime = st;
 #endif
         }
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 17:06:44 -0400

 At 9:44 PM +0200 6/19/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  Well, I committed some of the kern-related changes.  Bruce has
 >>  a few follow-on ideas though, so I might be doing something
 >  > different for ki_childstime and ki_childutime.
 >
 >I'll try the following code :
 
 Well, Bruce has some fix for one issue in that general area, but
 I think he would also like to see kern_proc return the child-
 related info in a different form, instead of using timeval's.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 19 Jun 2004 23:04:14 -0400

 At 9:44 PM +0200 6/19/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >  > Well, I committed some of the kern-related changes.  Bruce has
 >>  a few follow-on ideas though, so I might be doing something
 >  > different for ki_childstime and ki_childutime.
 >
 >I'll try the following code :
 >
 >         if ((p->p_sflag & PS_INMEM) && p->p_stats) {
 >                 struct timeval ut, st;
 >
 >                 kp->ki_start = p->p_stats->p_start;
 >                 timevaladd(&kp->ki_start, &boottime);
 >                 kp->ki_rusage = p->p_stats->p_ru;
 >                 calcru(p, &ut, &st, NULL);
 
 Yeah, this call to calcru was in Bruce's updates, and it does fix
 the problem I was asking about.  Bruce and I are still debating a
 variety of other issues about the kproc_info struct, though...
 
 So, I just committed the one-line fix to add calcru, and I am
 hoping to leave any remaining kern-related updates until after
 we have made some progress committing changes to `ps' itself.
 I am thinking of the timetable for "5.3-release", and I want to
 be sure to get user-visible *changes* committed soon.  We can
 always add whatever *new* features we want after 5.3-release.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: Garance A Drosehn <gad@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 03:55:48 +0200 (CEST)

 On Jun 19, 2004 05:06:44 pm -0400, Garance A Drosehn wrote:
 > At 9:44 PM +0200 6/19/04, Cyrille Lefevre wrote:
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >>  Well, I committed some of the kern-related changes.  Bruce has
 > >>  a few follow-on ideas though, so I might be doing something
 > >  > different for ki_childstime and ki_childutime.
 > >
 > >I'll try the following code :
 
 the above code was totally broken...  I update the child times instead
 of the current process times ! here is a new one which seems to work
 much better than using the p_stats->p_ru which seems not to be up-to-date.
 
         if ((p->p_sflag & PS_INMEM) && p->p_stats) {
                 struct timeval ut, st;
 
                 kp->ki_start = p->p_stats->p_start;
                 timevaladd(&kp->ki_start, &boottime);
                 kp->ki_rusage = p->p_stats->p_ru;
                 calcru(p, &ut, &st, NULL);
                 kp->ki_rusage.ru_utime = ut;
                 kp->ki_rusage.ru_stime = st;
                 kp->ki_childtime = p->p_stats->p_cru.ru_utime;
                 timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_stime);
 #ifdef PROC_CHILDTIMES
                 kp->ki_childutime = p->p_stats->p_cru.ru_utime;
                 kp->ki_childstime = p->p_stats->p_cru.ru_stime;
 #endif
         }
 
 > Well, Bruce has some fix for one issue in that general area, but
 > I think he would also like to see kern_proc return the child-
 > related info in a different form, instead of using timeval's.
 
 here is a patch set (relative to the last kernel and ps ones) which
 includes the above time fix plus some thread relate stuffs.
 it is not related to -head since I've not recently updated my src tree.
 
 --- sys/sys/user.h	Sun Jun 20 02:53:55 2004
 +++ /sys/sys/user.h	Sun Jun 20 00:35:22 2004
 @@ -163,8 +163,10 @@
  	rlim_t	ki_maxrss;		/* maximum resident set size */
  	struct	timeval ki_childstime;	/*system time used by process children*/
  	struct	timeval ki_childutime;	/* user time used by process children */
 -	long	ki_align[(sizeof(long)!=sizeof(int))*2]; /* auto-alignment */
 -	long	ki_spare[14];		/* spare constants */
 +	pid_t	ki_tid;			/* XXXKSE thread id */
 +	int	ki_numthreads;		/* XXXKSE number of threads in total */
 +	long	ki_align[(sizeof(long)!=sizeof(int))*3]; /* auto-alignment */
 +	long	ki_spare[12];		/* spare constants */
  };
  void fill_kinfo_proc(struct proc *, struct kinfo_proc *);
  
 --- sys/kern/kern_proc.c	Sun Jun 20 02:53:55 2004
 +++ /sys/kern/kern_proc.c	Sun Jun 20 02:57:34 2004
 @@ -48,6 +48,7 @@
  #include <sys/sched.h>
  #include <sys/smp.h>
  #include <sys/sysctl.h>
 +#include <sys/time.h>
  #include <sys/filedesc.h>
  #include <sys/tty.h>
  #include <sys/signalvar.h>
 @@ -704,15 +705,19 @@
  #endif
  	}
  	if ((p->p_sflag & PS_INMEM) && p->p_stats) {
 +		struct timeval ut, st;
 +
  		kp->ki_start = p->p_stats->p_start;
  		timevaladd(&kp->ki_start, &boottime);
  		kp->ki_rusage = p->p_stats->p_ru;
 -		timeradd(&p->p_stats->p_cru.ru_utime,
 -			 &p->p_stats->p_cru.ru_stime,
 -			 &kp->ki_childtime);
 +		calcru(p, &ut, &st, NULL);
 +		kp->ki_rusage.ru_utime = ut;
 +		kp->ki_rusage.ru_stime = st;
 +		kp->ki_childtime = p->p_stats->p_cru.ru_utime;
 +		timevaladd(&kp->ki_childtime, &p->p_stats->p_cru.ru_stime);
  #ifdef PROC_CHILDTIMES
 -		kp->ki_childstime = p->p_stats->p_cru.ru_stime;
  		kp->ki_childutime = p->p_stats->p_cru.ru_utime;
 +		kp->ki_childstime = p->p_stats->p_cru.ru_stime;
  #endif
  	}
  	if (p->p_state != PRS_ZOMBIE) {
 @@ -776,6 +781,10 @@
  		kp->ki_lastcpu = td->td_lastcpu;
  		kp->ki_oncpu = td->td_oncpu;
  		kp->ki_tdflags = td->td_flags;
 +#ifdef PROC_THREAD
 +		kp->ki_tid = td->td_tid;
 +		kp->ki_numthreads = p->p_numthreads;
 +#endif
  		kp->ki_pcb = td->td_pcb;
  		kp->ki_kstack = (void *)td->td_kstack;
  		kp->ki_pctcpu = sched_pctcpu(td);
 --- sys/conf/options	Sun Jun 20 02:53:56 2004
 +++ /sys/conf/options	Thu Jun 17 14:39:20 2004
 @@ -663,6 +663,8 @@
  PROC_EMUL		opt_proc.h
  # ki_maxrss
  PROC_MAXRSS		opt_proc.h
 +# ki_tid, ki_ntds, ki_numthreads, ki_nkses
 +PROC_THREAD		opt_proc.h
  # ki_cmask
  PROC_UMASK		opt_proc.h
  # implement KERN_PROC_SESSION
 diff -u bin/ps/Makefile /usr/src/bin/ps.new/Makefile
 --- bin/ps/Makefile	Sun Jun 20 02:55:00 2004
 +++ /usr/src/bin/ps.new/Makefile	Fri Jun 18 03:21:46 2004
 @@ -5,7 +5,16 @@
  SRCS=	fmt.c keyword.c nlist.c print.c ps.c
  LINKS=	${BINDIR}/ps ${BINDIR}/psx \
  	${BINDIR}/ps ${BINDIR}/bps
 -WARNS?=	5
 +WARNS?=	6
 +CWARNFLAGS?=	-ansi -Wbad-function-cast
 +.if defined(DEBUG_FLAGS)
 +# LIBKVM=		${.CURDIR}/../../lib/libkvm
 +# CFLAGS+=	-I${LIBKVM}
 +# .PATH:		${LIBKVM}
 +# SRCS+=		kvm_proc.c kvm.c kvm_i386.c
 +# NO_WERROR=	yes
 +# WFORMAT=	0
 +.endif
  #
  # To support "lazy" ps for non root/wheel users
  # add -DLAZY_PS to the cflags.  This helps
 @@ -73,6 +82,10 @@
  # kernel supports ki_maxrss (lim keyword).
  #
  CFLAGS+= -DWITH_MAXRSS
 +#
 +# kernel supports ki_tid, ki_ntds (lid or lwp, and nlwp keyword).
 +#
 +CFLAGS+= -DWITH_THREAD
  #
  # kernel supports ki_cmask (umask keyword).
  #
 diff -u bin/ps/keyword.c /usr/src/bin/ps.new/keyword.c
 --- bin/ps/keyword.c	Sun Jun 20 02:55:01 2004
 +++ /usr/src/bin/ps.new/keyword.c	Sun Jun 20 00:51:15 2004
 @@ -70,7 +70,9 @@
  #define COMMLEN	MAXCOMLEN	/* args, command, ucomm */
  #define DATELEN	28		/* lstart */
  #define DEVLEN	6		/* tdev */
 -// #define EMULLEN	7		/* emul */
 +#if 0
 +#define EMULLEN	7		/* emul */
 +#endif
  #define FLAGFMT	"x"		/* kvar */
  #define FLAGLEN	7		/* f */
  #define GRPLEN	USERLEN		/* group, rgroup, svgroup */
 @@ -80,6 +82,10 @@
  #define KPTRLEN	8		/* paddr, nwchan */
  #define LABLLEN	SHRT_MAX	/* label */
  #define LOCKLEN	6		/* lockname */
 +#define LIDFMT	"d"		/* kvar */
 +#define LIDLEN	6		/* lid, lwp */
 +#define LWPFMT	"d"		/* kvar */
 +#define LWPLEN	4		/* nlwp */
  #define PRIOFMT	"d"		/* kvar */
  #define PRIOLEN	3		/* cpu, intpri, jobc, nice, opri, pri, upr,
  				   pset, psr */
 @@ -125,6 +131,7 @@
  	{ n, h, NULL, fl, fn, NULL, ln##LEN, 0, CHAR, NULL, 0 }
  
  #define PID(n, h, s)	KVAR(n, h, s, UINT, PID)
 +#define LID(n, h, s)	KVAR(n, h, s, UINT, LID)
  #define SIG(n, h, s)	KVAR(n, h, s, UINT, SIG)
  #define UID(n, h, s)	KVAR(n, h, s, UINT, UID)
  #define GID(n, h, s)	UID(n, h, s)
 @@ -230,8 +237,8 @@
  /*#3  no     */	KVAR("ktracep", "KTRACEP", ki_tracep, KPTR, KPTR),
  #endif
  /*_  f    i  */	SIZE("label", "LABEL", LJUST, label, s_label, LABL),
 -#if defined(WITH_NOP_ALIASES)
 -/*#   n      */	CALL("lid", "LID", 0, nop, PID),	/* XXX nop */
 +#if defined(WITH_THREAD)
 +/*+   n      */	ALIAS("lid", NULL, "lwp"),		/* XXXKSE */
  #endif
  #if defined(WITH_MAXRSS)
  /*_34fno     */	CALL("lim", "LIM", 0, maxrss, LSZ),
 @@ -248,7 +255,9 @@
  /* 34fno    t*/	CALL("lstart", "STARTED", LJUST|USER, lstarted, DATE),
  #if defined(WITH_NOP_ALIASES)
  /*#   n      */	CALL("lstate", "LSTATE", 0, nop, STAT),	/* XXX nop */
 -/*#        s */	CALL("lwp", "LWP", 0, nop, PID),	/* XXX nop */
 +#endif
 +#if defined(WITH_THREAD)
 +/*+        s */	LID("lwp", "LWP", ki_tid),		/* XXXKSE */
  #endif
  /* 34fno    t*/	RVAR("majflt", "MAJFLT", ru_majflt, LONG, LCNT),
  #if defined(WITH_EXTRA_ALIASES)
 @@ -260,10 +269,10 @@
  /*_  f       */	CALL("mwchan", "MWCHAN", LJUST, mwchan, WCHN),
  /* 34fno    t*/	ALIAS("ni", NULL, "nice"),
  /*_34fnoxhist*/	KVAR("nice", "NI", ki_nice, CHAR, PRIO),
 -#if defined(WITH_NOP_ALIASES)
 -/*#   n    s */	CALL("nlwp", "NLWP", 0, nop, PID),	/* XXX nop */
 -#endif
  /* 34fno    t*/	RVAR("nivcsw", "NIVCSW", ru_nivcsw, LONG, SCNT),
 +#if defined(WITH_THREAD)
 +/*+   n    s */	KVAR("nlwp", "NLWP", ki_numthreads, INT, LWP),	/* XXXKSE */
 +#endif
  /* 34fno    t*/	ALIAS("nsignals", NULL, "nsigs"),
  /* 34fno    t*/	RVAR("nsigs", "NSIGS", ru_nsignals, LONG, SCNT),
  /* 34fno    t*/	RVAR("nswap", "NSWAP", ru_nswap, LONG, SCNT),
 diff -u bin/ps/print.c /usr/src/bin/ps.new/print.c
 --- bin/ps/print.c	Sun Jun 20 02:55:01 2004
 +++ /usr/src/bin/ps.new/print.c	Sun Jun 20 03:33:27 2004
 @@ -792,15 +792,8 @@
  		secs = k->ki_p->ki_runtime / 1000000;
  		psecs = k->ki_p->ki_runtime % 1000000;
  		if (sumrusage) {
 -#if defined(WITH_CHILDTIMES)
 -			secs += k->ki_p->ki_childstime.tv_sec +
 -				k->ki_p->ki_childutime.tv_sec;
 -			psecs += k->ki_p->ki_childstime.tv_usec +
 -				k->ki_p->ki_childutime.tv_usec;
 -#else
  			secs += k->ki_p->ki_childtime.tv_sec;
  			psecs += k->ki_p->ki_childtime.tv_usec;
 -#endif
  		}
  	}
  	printtime(secs, psecs, v->width, 0);
 @@ -818,15 +811,8 @@
  		secs = 0;
  		psecs = 0;
  	} else {
 -#if defined(WITH_CHILDTIMES)
 -		secs = k->ki_p->ki_childstime.tv_sec +
 -			k->ki_p->ki_childutime.tv_sec;
 -		psecs = k->ki_p->ki_childstime.tv_usec +
 -			k->ki_p->ki_childutime.tv_usec;
 -#else
  		secs = k->ki_p->ki_childtime.tv_sec;
  		psecs = k->ki_p->ki_childtime.tv_usec;
 -#endif
  	}
  	printtime(secs, psecs, v->width, 0);
  }
 
 here is a simple threaded program for testing purpose.
 you can compile it in two way :
 
 cc -o thread thread.c -lthr
 or
 cc -pthread -o pthread thread.c
 
 the first one forks 5 visible threads (plus the father), and the
 second one, only 1 visible threads (plus the father) !
 so, it seems to be better to compile w/ -lthr than w/ -pthread...
 
 to see them, use : ./thread & sleep 1; ps -O lwp,nlwp -qLC thread
 
 #define _REENTRANT
 #include <pthread.h>
  
 #define NUM_THREADS 5
 #define SLEEP_TIME 10
  
 void *sleeping(void *);
 pthread_t tid[NUM_THREADS];
  
 int
 main(int argc, char *argv[])
 {
 	int i;
 
 	for (i = 0; i < NUM_THREADS; i++)
 		pthread_create(&tid[i], NULL, sleeping, (void *)SLEEP_TIME);
 	for (i = 0; i < NUM_THREADS; i++)
 		pthread_join(tid[i], NULL);
 	printf("main() reporting that all %d threads have terminated\n", i);
 	return (0);
 }
  
 void *
 sleeping(void *arg)
 {
 	int sleep_time = (int)arg;
 	printf("thread %d sleeping %d seconds ...\n", thr_self(), sleep_time);
 	sleep(sleep_time);
 	printf("\nthread %d awakening\n", thr_self());
 	return (NULL);
 }
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Garance A Drosehn <gad@FreeBSD.org>
To: cyrille.lefevre@laposte.net
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 00:53:18 -0400

 At 3:55 AM +0200 6/20/04, Cyrille Lefevre wrote:
 >On Jun 19, 2004 05:06:44 pm -0400, Garance A Drosehn wrote:
 >  > Well, Bruce has some fix for one issue in that general area, but
 >  > I think he would also like to see kern_proc return the child-
 >>  related info in a different form, instead of using timeval's.
 >
 >here is a patch set (relative to the last kernel and ps ones) which
 >includes the above time fix plus some thread relate stuffs.
 
 Sigh.  I am very close to just giving up on this PR.  You are
 generating new patches faster than I can commit things.  On the
 other hand, I will admit that it would be awfully nice to get
 the ki_numthreads information up to the `ps' command level...
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "Garance A Drosehn" <gad@FreeBSD.org>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 09:17:49 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 3:55 AM +0200 6/20/04, Cyrille Lefevre wrote:
 > >On Jun 19, 2004 05:06:44 pm -0400, Garance A Drosehn wrote:
 > >  > Well, Bruce has some fix for one issue in that general area, but
 > >  > I think he would also like to see kern_proc return the child-
 > >>  related info in a different form, instead of using timeval's.
 > >
 > >here is a patch set (relative to the last kernel and ps ones) which
 > >includes the above time fix plus some thread relate stuffs.
 > 
 > Sigh.  I am very close to just giving up on this PR.  You are
 > generating new patches faster than I can commit things.  On the
 
 yeah! I'm the one how fire faster than its shadow :)
 
 > other hand, I will admit that it would be awfully nice to get
 > the ki_numthreads information up to the `ps' command level...
 
 as ki_tid too, no ?
 
 Ps : I don't now if ki_nkse (kgp_kses) and ki_numksegrps (p_numksegrps)
 are also usefull ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc: "Bruce Evans" <bde@zeta.org.au>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 09:30:31 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > At 9:44 PM +0200 6/19/04, Cyrille Lefevre wrote:
 > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > >  > Well, I committed some of the kern-related changes.  Bruce has
 > >>  a few follow-on ideas though, so I might be doing something
 > >  > different for ki_childstime and ki_childutime.
 > >
 > >I'll try the following code :
 > >
 > >         if ((p->p_sflag & PS_INMEM) && p->p_stats) {
 > >                 struct timeval ut, st;
 > >
 > >                 kp->ki_start = p->p_stats->p_start;
 > >                 timevaladd(&kp->ki_start, &boottime);
 > >                 kp->ki_rusage = p->p_stats->p_ru;
 > >                 calcru(p, &ut, &st, NULL);
 > 
 > Yeah, this call to calcru was in Bruce's updates, and it does fix
 > the problem I was asking about.  Bruce and I are still debating a
 > variety of other issues about the kproc_info struct, though...
 
 why don't you debate this in public ? or at least, CC -gnats on this
 PR ?
 
 > So, I just committed the one-line fix to add calcru, and I am
 
 hup! this can't be a one line fix, since calcru() seems to require
 to be Giant locked. that's why I use temporary variables instead of
 updating the proc structure to not slow down the system by locking
 every ps entries. for details about calcru(), see exit1() in
 kern_exit.c and getrusage in kern_resource.c. at least, this would
 have to be :
 
 mtx_lock(&Giant);
 mtx_lock_spin(&sched_lock);
 calcru(p, &p->p_stats->p_ru.ru_utime, &p->p_stats->p_ru.ru_stime, NULL);
 mtx_unlock_spin(&sched_lock);
 kp->ki_rusage = p->p_stats->p_ru;
 mtx_unlock(&Giant);
 
 but, this consume too much resources, IMHO.
 
 > hoping to leave any remaining kern-related updates until after
 > we have made some progress committing changes to `ps' itself.
 > I am thinking of the timetable for "5.3-release", and I want to
 > be sure to get user-visible *changes* committed soon.  We can
 > always add whatever *new* features we want after 5.3-release.
 
 CC -bde
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 09:44:56 +0200

 Hi,
 
 just seen that you added 2 fields named ki_ps_segsz1 and ki_ps_float1
 to kinfo_proc. are they filled by the kernel or by ps ? if filled by
 the kernel, ok, but if filled and used by ps, they should go in KINFO
 (ps.h) instead which is ps internal. I'm asking because it is not clear
 what they are for ?
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Bruce Evans <bde@zeta.org.au>
To: Cyrille Lefevre <cyrille.lefevre@laposte.net>
Cc: freebsd-gnats-submit@freebsd.org,
	Garance A Drosehn <gad@freebsd.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 22:23:50 +1000 (EST)

 On Sun, 20 Jun 2004, Cyrille Lefevre wrote:
 
 > "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > > At 9:44 PM +0200 6/19/04, Cyrille Lefevre wrote:
 > > >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > > >  > Well, I committed some of the kern-related changes.  Bruce has
 > > >>  a few follow-on ideas though, so I might be doing something
 > > >  > different for ki_childstime and ki_childutime.
 > > >
 > > >I'll try the following code :
 > > >
 > > >         if ((p->p_sflag & PS_INMEM) && p->p_stats) {
 > > >                 struct timeval ut, st;
 > > >
 > > >                 kp->ki_start = p->p_stats->p_start;
 > > >                 timevaladd(&kp->ki_start, &boottime);
 > > >                 kp->ki_rusage = p->p_stats->p_ru;
 > > >                 calcru(p, &ut, &st, NULL);
 > >
 > > Yeah, this call to calcru was in Bruce's updates, and it does fix
 > > the problem I was asking about.  Bruce and I are still debating a
 > > variety of other issues about the kproc_info struct, though...
 >
 > why don't you debate this in public ? or at least, CC -gnats on this
 > PR ?
 
 It's easier to discuss things in private.  I just pointed out that a
 commit overlapped with some of my local changes that were made for
 unrelated reasons (to avoid calling calcru() in exit()).  The above
 calcru() call was a side effect (I needed a similar call for child
 times).
 
 > > So, I just committed the one-line fix to add calcru, and I am
 >
 > hup! this can't be a one line fix, since calcru() seems to require
 > to be Giant locked. that's why I use temporary variables instead of
 > updating the proc structure to not slow down the system by locking
 > every ps entries. for details about calcru(), see exit1() in
 > kern_exit.c and getrusage in kern_resource.c. at least, this would
 > have to be :
 > ...
 
 calcru() only requires sched_lock and possibly PROC_LOCK() (except
 in my version (*)), and both of these locks are already held in
 fill_kinfo_thread(), so the fix really is one-line and the only slowness
 is in the actual call.
 
 > but, this consume too much resources, IMHO.
 
 calcru() itself consumes too much resources, but I'm not worried about
 this here (except see (*)) since I think fill_kinfo_thread() is mainly
 used for interactive purposes.
 
 (*) My calcru() aquires locks as necessary and only holds sched_lock
 for a few instructions, but some callers including fill_kinfo_thread()
 want to hold sched_lock across most of their operation to get a coherent
 as possible snapshot of the process state.  I have't figured out how
 to deal with this.
 
 Bruce

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc: "Bruce Evans" <bde@zeta.org.au>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 08:24:40 -0400

 At 9:30 AM +0200 6/20/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >  >
 >  > Yeah, this call to calcru was in Bruce's updates, and it does
 >  > fix the problem I was asking about.  Bruce and I are still
 >  > debating a variety of other issues about the kproc_info
 >  > struct, though...
 >
 >why don't you debate this in public ? or at least, CC -gnats
 >on this PR ?
 
 When it comes to debating Bruce, I am just more comfortable doing
 that debate via private emails.  So far this year, I have caught
 him in an error once, and he's caught me in a error about 83
 times.  I would rather not embarrass myself by having all that
 done in public...
 
 The bigger question is why Bruce is willing to put up with all
 of my rambling messages!
 
 Besides, sometimes the debate is over what the *present* change
 should be, and other times it is over we would like to do at
 some point in the future.  I must have at least a hundred messages
 from Bruce about things that I "intend to get back to" once I have
 some spare time.   (assuming I ever have any spare time)
 
 >  > So, I just committed the one-line fix to add calcru, and I am
 >
 >hup! this can't be a one line fix, since calcru() seems to
 >require to be Giant locked.
 
 The change updates the version in the kproc_info struct that we
 are returning, not the system copy.  I believe that we do not
 need a lock for that.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 10:11:04 -0400

 At 9:17 AM +0200 6/20/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  At 3:55 AM +0200 6/20/04, Cyrille Lefevre wrote:
 >>  >On Jun 19, 2004 05:06:44 pm -0400, Garance A Drosehn wrote:
 >>  >  > Well, Bruce has some fix for one issue in that general area, but
 >>  >  > I think he would also like to see kern_proc return the child-
 >>  >>  related info in a different form, instead of using timeval's.
 >>  >
 >>  >here is a patch set (relative to the last kernel and ps ones) which
 >>  >includes the above time fix plus some thread relate stuffs.
 >>
 >>  Sigh.  I am very close to just giving up on this PR.  You are
 >>  generating new patches faster than I can commit things.  On the
 >
 >yeah! I'm the one how fire faster than its shadow :)
 
 The problem is that my own shadow can often draw a gun much
 faster than I can...
 
 >  > other hand, I will admit that it would be awfully nice to get
 >>  the ki_numthreads information up to the `ps' command level...
 >
 >as ki_tid too, no ?
 
 Indeed, I meant that both of those values would be nice to have.
 
 >Ps : I don't now if ki_nkse (kgp_kses) and ki_numksegrps
 >(p_numksegrps) are also usefull ?
 
 They probably will be, but I would rather not worry about those
 at this time.
 
 >just seen that you added 2 fields named ki_ps_segsz1 and
 >ki_ps_float1 to kinfo_proc. ... I'm asking because it is not
 >clear what they are for ?
 
 They are for *my* pending updates to `ps'.  However, Bruce is
 also debating me on those two variables, so I may handle them
 a different way.  I am still mulling over a few different ways
 to handle those.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 17:09:23 -0400

 At 9:44 AM +0200 6/20/04, Cyrille Lefevre wrote:
 >Hi,
 >
 >just seen that you added 2 fields named ki_ps_segsz1 and ki_ps_float1
 >to kinfo_proc. are they filled by the kernel or by ps ? if filled by
 >the kernel, ok, but if filled and used by ps, they should go in KINFO
 >(ps.h) instead which is ps internal.
 
 Well, you are quite right.  I can't remember what problem I ran into
 when I tried that before, but obviously that will work much better
 than what I was going to do.  Thanks!
 
 [thinking about it some more, I suspect I had out-smarted myself
 with a macro I wrote, and I had it checking fields in ki_p instead
 of in KINFO -- and it was doing that for no good reason.  Major
 brain-fault on my part]
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 20 Jun 2004 21:24:31 -0400

 Well, I got a few more little updates committed.  I was going to
 try for systime + usertime, but my first attempt to add that has
 some minor mixup in the format (extra blanks, but only on *some*
 tasks).  Probably a typo on my part.
 
 I hope to get something committed for that, but other than that I
 doubt I will have much time to work on `ps' this week or early
 next week.  But at least I have made some forward progress, and
 people can use some of the new features you have implemented.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc: "Christian S.J. Peron" <csjp@FreeBSD.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 17:39:24 -0400

 Hi Cyrille.
 
 So I have committed the updates which implement KERN_PROC_GID.  I
 do not notice any change to use that in `ps'.  Did you plan to?
 
 Christian SJ Peron <csjp@freebsd.org> wrote me:
 >Was there any reason we are not checking supplementary groups as
 >well as primary groups?
 >
 >Since one of the fundemental principals of groups in BSD is the
 >ability for a subject to be a part of multiple groups, shouldn't
 >we be matching on supplementary groups?
 
 I notice that when it comes to output formats, your update
 adds (among other things):
 
      egid      EGID      effective group id [netbsd/openbsd]
      egroup    EGROUP    group name (from egid) [netbsd/openbsd]
      gid       GID       effective group id [netbsd/openbsd]
      group     GROUP     group name (from gid) [openbsd/hpux/
                                             irix/solaris/tru64]
      groups    GROUPS    group access list [netbsd/openbsd]
      groupnames GROUPNAMES group names (from group access list)
                            [netbsd/openbsd]
      svgroup   SVGROUP   group name (from svgid) [netbsd/openbsd]
      svuser    SVUSER    user name (from svuid) [netbsd/openbsd]
 
 In this case, gid/group are just synonyms to egid/egroup, and the
 values that Christian in interested in show up as group/groupnames.
 I think this implies that if we want to select based on all
 supplementary groups, then we might want to do it as different
 selector.  Maybe KERN_PROC_SUPGID or KERN_PROC_ANYGID.
 
 I don't know if any other OS has something like this, but I can
 see where it might be useful under some circumstances.  So, what
 do you think?  Christian included the following update for
 kern_proc.c, and it would obviously be trivial to do the same
 kind of thing in kvm_proc.c:
 
 Index: kern_proc.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
 retrieving revision 1.211
 diff -u -r1.211 kern_proc.c
 --- kern_proc.c	20 Jun 2004 22:17:22 -0000	1.211
 +++ kern_proc.c	21 Jun 2004 04:57:21 -0000
 @@ -988,7 +988,7 @@
 
   			case KERN_PROC_GID:
   				if (p->p_ucred == NULL ||
 -				    p->p_ucred->cr_gid != (gid_t)name[0]) {
 +				    !groupmember((gid_t)name[0], p->p_ucred)) {
   					PROC_UNLOCK(p);
   					continue;
   				}
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 18:00:29 -0400

 Btw, in your patch for the tty-related changes to kern_proc.c, you
 have a section:
 
 		SESS_LOCK(p->p_session);
 		if ((p->p_session->s_ttyp == NULL &&
 		     (udev_t)name[0] != KERN_PROC_TTY_NODEV) ||
 		    (p->p_session->s_ttyp != NULL &&
 		     (((udev_t)name[0] == KERN_PROC_TTY_REVOKE &&
 		       p->p_session->s_ttyvp != NULL) ||
 		      ((udev_t)name[0] != KERN_PROC_TTY_REVOKE &&
 		       dev2udev(p->p_session->s_ttyp->t_dev) !=
 		       (udev_t)name[0]))))
 		{
 			SESS_UNLOCK(p->p_session);
 			PROC_UNLOCK(p);
 			continue;
 		}
 		SESS_UNLOCK(p->p_session);
 		break;
 
 I tried to read through that several times, and it is just too
 much in a single if-condition for me to easily parse.  So, in the
 version that I almost committed (before the udev_t change scared
 me away), I changed that to:
 
 		tty_wanted = (udev_t)name[0];
 			[... skipped lines ...]
 		matched = 0;
 		SESS_LOCK(p->p_session);
 		if (tty_wanted == KERN_PROC_TTY_NODEV) {
 			if (p->p_session->s_ttyp == NULL)
 				matched = 1;
 		} else if (tty_wanted == KERN_PROC_TTY_REVOKE) {
 			if (p->p_session->s_ttyp != NULL &&
 			    p->p_session->s_ttyvp == NULL)
 				matched = 1;
 		} else if (p->p_session->s_ttyp != NULL) {
 			if (tty_wanted ==
 			  dev2udev(p->p_session->s_ttyp->t_dev))
 				matched = 1;
 		}
 		SESS_UNLOCK(p->p_session);
 		if (!matched) {
 			PROC_UNLOCK(p);
 			continue;
 		}
 		break;
 
 I find that much easier for someone to understand at a glance.  I
 had not yet done a similar change for kvm_proc.c.  The code there
 isn't quite as hard to follow, and I was also in a bit of a rush
 by the time I got that.  But when I get back to the tty-changes
 I might do something similar there, too.
 
 I am pretty sure the logic comes out exactly the same in the two
 versions, but I want to be sure that the logic for the TTY_REVOKE
 section is correct.  I simply do not know enough about the kernel-
 level processing to say if that's really what you want to select.
 When I tested it, it seemed to only match one process on my system.
 That process *was* one which had revoked a tty, but I have the vague
 feeling that it should have matched some other processes too.  Should
 that match some daemons, maybe?  However, I am not a kernel wizard,
 and I do not really wish to become one...  Let me know if that logic
 looks about right to you.
 
 [I started out on that section just because it is a style error.
 All the lines after the first one should line up with a 4-character
 indent, but fixing that just made it even HARDER to read...]
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosehn <gad@FreeBSD.org>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 20:26:06 -0400

 A minor thing I noticed while poking around today...
 
 (39) ps -l
    UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT  TT       TIME COMMAND
      0  7779  1113   0  96  0  1368  864 -      R+    p2    0:00.00 ps -l
 
 (40)  ps-cyr -l
    UID   PID  PPID CPU PRI  NI   VSZ   RSS MWCHAN STAT TT       TIME COMMAND
      0  7780  1113   1  96   0  1432  1028 -      O+   p2    0:00.00 ps-cyr -l
 
 It seems that the full-updated `ps' consistently has a larger RSS...
 (I expect that is not much of an issue).
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "Bruce Evans" <bde@zeta.org.au>
Cc: <freebsd-gnats-submit@freebsd.org>,
	"Garance A Drosehn" <gad@freebsd.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 02:46:19 +0200

 "Bruce Evans" <bde@zeta.org.au> wrote:
 > On Sun, 20 Jun 2004, Cyrille Lefevre wrote:
 > > "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 [snip]
 > > > So, I just committed the one-line fix to add calcru, and I am
 > >
 > > hup! this can't be a one line fix, since calcru() seems to require
 > > to be Giant locked. that's why I use temporary variables instead of
 > > updating the proc structure to not slow down the system by locking
 > > every ps entries. for details about calcru(), see exit1() in
 > > kern_exit.c and getrusage in kern_resource.c. at least, this would
 > > have to be :
 > > ...
 >
 > calcru() only requires sched_lock and possibly PROC_LOCK() (except
 > in my version (*)), and both of these locks are already held in
 > fill_kinfo_thread(), so the fix really is one-line and the only slowness
 
 forgot about that :)
 
 > is in the actual call.
 
 if the Giant lock isn't necessary, maybe you can get rid of it in getrusage() ?
 not sure about exit1(), my kernel knowledge is not so deep :(
 
 > > but, this consume too much resources, IMHO.
 >
 > calcru() itself consumes too much resources, but I'm not worried about
 > this here (except see (*)) since I think fill_kinfo_thread() is mainly
 > used for interactive purposes.
 
 about the consummation, I was talking about locks, not about calcru() by itself.
 also, as Garance said :
 
     "The change updates the version in the kproc_info struct that we
     are returning, not the system copy.  I believe that we do not
     need a lock for that."
 
 [snip]
 
 thanks for your explanations.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 21:36:02 -0400

 The summary of your changes includes the section:
 
     <quote "right">
     When printing using the command keyword, a process that has exited
     and has a parent that has not yet waited for the process (in other
     words, a zombie) is listed as ``<defunct>''.
     </quote>
 
     <quote "wrong">
     and a process which is blocked while trying to exit is listed as
     ``<exiting>''
     </quote>
 
     <cite "netbsd">
     If the command vector cannot be located (usually because it has
     not been set, as is the case of system processes and/or kernel
     threads) the command name is printed within square brackets.
     </cite>
 
 What is "wrong" about what we do?  Is it just that we are different
 from NetBSD?  That would be a reasonable answer, but I am wondering
 if there any other OS's which behave the same way.  A quick glance
 suggests that linux might.  Any others?  Solaris, AIX, and OpenBSD
 do not seem to, but then they do not seem to show any "system
 processes or kernel threads", so maybe that is irrelevant.
 
 Also, is there any conflict between the part you say is "wrong",
 and the part you describe from NetBSD?  I do not see any processes
 listed as ``<exiting>'' with the standard `ps' on my system.  When
 comparing the output from 'ps -axo command', the major difference
 seems to be that processes in yours showing up as:
 
 [acpi_task0]
 [acpi_task1]
 [acpi_task2]
 
 Instead of looking like:
 
   (acpi_task0)
   (acpi_task1)
   (acpi_task2)
 
 That has nothing to do with ``<exiting>''.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc: "Christian S.J. Peron" <csjp@FreeBSD.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 03:39:01 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > So I have committed the updates which implement KERN_PROC_GID.  I
 > do not notice any change to use that in `ps'.  Did you plan to?
 
 AFAIK, there is no existing ps which implement this, so, the answer
 is no, I do not plan to do anything regarding KERN_PROC_GID.
 I just add KERN_PROC_*GID to mirror KERN_PROC_*UID and other *BSD.
 however, 
 
 > Christian SJ Peron <csjp@freebsd.org> wrote me:
 > >Was there any reason we are not checking supplementary groups as
 > >well as primary groups?
 
 yes, AFAIK, no other existing ps does this, and our (Garance and I)
 current work is to follow what other existing implementations of ps
 does.
 
 > >Since one of the fundemental principals of groups in BSD is the
 > >ability for a subject to be a part of multiple groups, shouldn't
 > >we be matching on supplementary groups?
 
 yes and no, since ps has no selector to show processes by egid :)
 
 > I notice that when it comes to output formats, your update
 > adds (among other things):
 [snip]
 > In this case, gid/group are just synonyms to egid/egroup, and the
 
 as NetBSD and OpenBSD does.
 
 > values that Christian in interested in show up as group/groupnames.
 > I think this implies that if we want to select based on all
 > supplementary groups, then we might want to do it as different
 > selector.  Maybe KERN_PROC_SUPGID or KERN_PROC_ANYGID.
 
 the problem is... what selectors. ps (as ls) is one of the command
 which use many selectors and there is not much free selectors :(
 
 what do you mean by KERN_PROC_ANYGID ?
 
 PS : remember that I currently reserve -qQ for future use (one of
 the few free selectors not used by BSD and POSIX) since you
 got -X :) I will probably go back to something like -q posix, etc.
 to free up a selector.
 
 > I don't know if any other OS has something like this, but I can
 > see where it might be useful under some circumstances.  So, what
 > do you think?  Christian included the following update for
 > kern_proc.c, and it would obviously be trivial to do the same
 > kind of thing in kvm_proc.c:
 
 well, since no other ps does this and since no standard says some-
 thing about that, I suppose we can find a selector to show processes
 by egid and/or effective group name. however, I think would be better
 to have a different kernel selector (KERN_PROC_SUPGID) for that.
 however, instead of adding one or 2 selectors, I propose to implement
 a better personality change than the one I submitted in the current
 PR. a sort of the one I propose some month later, do you remember
 that ? let's imagine :
 
 ps -G gid
 -> real gid
 ps -q egid -G gid
 -> effective gid
 ps -q member -G gid
 -> supplemental gids
 
 so, this may also work for the posix :)
 
 PS : this week, I'll merge my PR w/ -current to reduce the diffs
 and probably reimplement -q personality in a simplier way than
 before.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 21:51:21 -0400

 Well, no need to reply to my last message.  The change to use
 square-brackets instead of parenthesis seems pretty reasonable,
 so I will just commit that part.  It is just that I do not
 understand the reference to <exitting> ...
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 21 Jun 2004 22:40:55 -0400

 At 3:39 AM +0200 6/22/04, Cyrille Lefevre wrote:
 
 >  > values that Christian in interested in show up as group/groupnames.
 >>  I think this implies that if we want to select based on all
 >>  supplementary groups, then we might want to do it as different
 >>  selector.  Maybe KERN_PROC_SUPGID or KERN_PROC_ANYGID.
 >
 >the problem is... what selectors. ps (as ls) is one of the command
 >which use many selectors and there is not much free selectors :(
 >
 >what do you mean by KERN_PROC_ANYGID ?
 
 I was making multiple suggestions for the same thing.  I thought
 some people might find "ANYGID" would be a more obvious name for
 that selector.  However, "SUPGID" is certainly fine with me.
 
 >PS : remember that I currently reserve -qQ for future use (one
 >of the few free selectors not used by BSD and POSIX) since you
 >got -X :) I will probably go back to something like -q posix,
 >etc. to free up a selector.
 
 At the moment I am very reluctant to use up any more letter
 options for anything, so I have no plans to add more.  It
 was not until after I sent my last message that it occurred
 to me that we would have to add another option to `ps' if we
 wanted to support more selectors...  We can think about that
 later.  Right now I am in no hurry to add more letter-options.
 
 However, I am quite willing to add 'group' and 'groupnames' as
 new output options.  There is much less chance of that causing
 a conflict with some other version of `ps'.
 
 >however, instead of adding one or 2 selectors, I propose to
 >implement a better personality change than the one I submitted
 >in the current PR. a sort of the one I propose some month later,
 >do you remember that? let's imagine :
 >
 >ps -G gid
 >-> real gid
 >ps -q egid -G gid
 >-> effective gid
 >ps -q member -G gid
 >-> supplemental gids
 
 Well, I still have not decided if I want to handle personality
 changes like that.  I have no plans of using -q or -Q for any of
 my own work that I have yet to commit, so you are free to use it
 as far as my work is concerned.
 
 >PS : this week, I'll merge my PR w/ -current to reduce the
 >diffs and probably reimplement -q personality in a simplier
 >way than before.
 
 If you were going to work on new updates, it would be better to
 work on a few SMALL pieces of your updates which I could commit
 on top of the present source, instead of another massive update.
 
 On the other hand, I haven't looked closely enough at what you
 have left to know which small updates to suggest.  The change
 to use [] was certainly small, but it was so small that it was
 quite easy for me to just go ahead and commit it...  :-)
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 05:04:47 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > Btw, in your patch for the tty-related changes to kern_proc.c, you
 > have a section:
                                 if ((p->p_flag & P_CONTROLT) == 0 ||
                                     p->p_session == NULL) {
 #ifdef PROC_TTY
                                         if ((udev_t)name[0] ==
 KERN_PROC_TTY_NODEV)
                                                 break;
 #endif
                                         PROC_UNLOCK(p);
                                         continue;
                                 }
 
 just to be sure you didn't forget the above test :)
 
 [snip my code]
 
 > I tried to read through that several times, and it is just too
 > much in a single if-condition for me to easily parse.  So, in the
 > version that I almost committed (before the udev_t change scared
 > me away), I changed that to:
 >
 > tty_wanted = (udev_t)name[0];
 
 please, don't. that does not follow the code around.
 
 > [... skipped lines ...]
 > matched = 0;
 > SESS_LOCK(p->p_session);
 > if (tty_wanted == KERN_PROC_TTY_NODEV) {
 > if (p->p_session->s_ttyp == NULL)
 > matched = 1;
 > } else if (tty_wanted == KERN_PROC_TTY_REVOKE) {
 > if (p->p_session->s_ttyp != NULL &&
 >     p->p_session->s_ttyvp == NULL)
 > matched = 1;
 > } else if (p->p_session->s_ttyp != NULL) {
 > if (tty_wanted ==
 >   dev2udev(p->p_session->s_ttyp->t_dev))
 > matched = 1;
 > }
 > SESS_UNLOCK(p->p_session);
 > if (!matched) {
 > PROC_UNLOCK(p);
 > continue;
 > }
 > break;
 
 I hate gnats...
 
 the last "else if" could be :
 
 } else if (p->p_session->s_ttyp != NULL &&
     tty_wanted == dev2udev(p->p_session->s_ttyp->t_dev))
         matched = 1;
 }
 
 however, see below.
 
 > I find that much easier for someone to understand at a glance.  I
 
 maybe, but that not follow what's around and when I do things, I
 try to always follow what done around, even if I dislike the way
 it is.
 
 PS : it's not my fault if the code around has an inverted logic.
 
 > had not yet done a similar change for kvm_proc.c.  The code there
 > isn't quite as hard to follow, and I was also in a bit of a rush
 > by the time I got that.  But when I get back to the tty-changes
 > I might do something similar there, too.
 
 I also past some time to write this single if-condition to reduce
 the code size (no multiple SESS_UNLOCK() and PROC_UNLOCK()).
 however, using a temp var is not a bad idea, see below.
 
 > I am pretty sure the logic comes out exactly the same in the two
 > versions, but I want to be sure that the logic for the TTY_REVOKE
 > section is correct.  I simply do not know enough about the kernel-
 
 I've written a test program to validate my logic. I write it down
 your logic and it is also right. however, if you dislike the way
 I go, I propose you to go the way NetBSD go, which is, translated
 to our needs :
 
 the above code (P_CONTROL, etc.) followed by :
 
 matched = 0;
 SESS_LOCK(p->p_session);
 if ((udev_t)name[0] == KERN_PROC_TTY_REVOKE) {
         if (p->p_session->s_ttyp == NULL ||
             p->p_session->s_ttyvp != NULL)
                 matched = 1;
 } else if (p->p_session->s_ttyp == NULL) {
            if ((udev_t)name[0] != KERN_PROC_TTY_NODEV)
                 matched = 1;
 } else if (dev2udev(p->p_session->s_ttyp->t_dev) != (udev_t)name[0])
         matched = 1;
 SESS_UNLOCK(p->p_session);
 if (matched) {
         PROC_UNLOCK(p);
 
 > level processing to say if that's really what you want to select.
 > When I tested it, it seemed to only match one process on my system.
 
 on my system, I have only 2 such process (attached to consolectl) :
 
 # bps -O tty -t-
   PID TTY        TT  STAT      TIME COMMAND
 66445 consolectl co- S+     7:32.70 /usr/local/bin/perl -Tw /usr/local/libexec/
 79660 consolectl co- S      0:10.81 /usr/local/sbin/junkbuster configfile
 
 > That process *was* one which had revoked a tty, but I have the vague
 > feeling that it should have matched some other processes too.  Should
 
 so, it should only match those w/o KI_CTTY (aka the ones terminated by
 a "-" in the tt field).
 
 > that match some daemons, maybe?  However, I am not a kernel wizard,
 
 daemons are mostly matched by ps -t? (the ones w/ ?? in the tt field).
 
 > and I do not really wish to become one...  Let me know if that logic
 > looks about right to you.
 
 let's try the program I'll send you separately :)
 
 > [I started out on that section just because it is a style error.
 > All the lines after the first one should line up with a 4-character
 > indent, but fixing that just made it even HARDER to read...]
 
 that's why I didn't follow style(9) here... to line-up conditions.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: Garance A Drosehn <gad@freebsd.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 05:08:24 +0200 (CEST)

 // here is the offending test code :)
 
 struct {
 	int pid;
 	int ttyvp;
 	int control;
 	int ttyp;
 	int tdev;
 	int session;
 } s[] = {
 	{ 1, 1, 1, 1,  1, 0 },
 	{ 2, 1, 1, 0, -1, 0 },
 	{ 3, 1, 0, 1, -1, 0 },
 	{ 4, 1, 0, 0, -1, 0 },
 	{ 5, 0, 1, 1,  2, 0 },
 	{ 6, 0, 1, 0, -1, 0 },
 	{ 7, 0, 0, 1, -1, 0 },
 	{ 8, 0, 0, 0, -1, 0 },
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 void
 foo(int n)
 {
 	int i;
 
 	printf("%d:\n", n);
 	for (i = 0; s[i].pid; i++) {
 		int x;
 		s[i].session = s[i].ttyp + s[i].ttyvp;
 		if (n == -2) {
 			if (s[i].control == 0 ||
 			    s[i].ttyp == 0 ||
 			    s[i].ttyvp != 0)
 				continue;
 			else
 				x = 1;
 		} else if (s[i].control == 0 ||
 			   s[i].ttyp == 0) {
 			if (n != -1)
 				continue;
 			else
 				x = 2;
 		} else if (s[i].tdev != n)
 			continue;
 		else
 			x = 3;
 		printf ("\t%d %d:%d:%d:%d:%d\n", x, s[i].pid, s[i].ttyvp,
 			s[i].control, s[i].ttyp, s[i].tdev);
 	}
 }
 
 void
 bar(int n)
 {
 	int i;
 
 	printf("%d:\n", n);
 	for (i = 0; s[i].pid; i++) {
 		int x = 0;
 		if (s[i].control == 0 ||
 		    s[i].session == 0) {
 			if (n != -1)
 				continue;
 		} else {
 			if ((s[i].ttyp == 0 && n != -1) ||
 			    (s[i].ttyp != 0 &&
 			     (n == -2 && s[i].ttyvp != 0) ||
 			     (n != -2 && s[i].tdev != n)))
 				continue;
 		}
 		printf ("\t%d %d:%d:%d:%d:%d\n", x, s[i].pid, s[i].ttyvp,
 			s[i].control, s[i].ttyp, s[i].tdev);
 	}
 }
 
 void
 foobar(int n)
 {
 	int i;
 
 	printf("%d:\n", n);
 	for (i = 0; s[i].pid; i++) {
 		int x = 0;
 		if (s[i].control == 0 ||
 		    s[i].session == 0) {
 			if (n != -1)
 				continue;
 		} else {
 			int m = 0;
 			if (n == -1) {
 				if (s[i].ttyp == 0)
 					m = 1;
 			} else if (n == -2) {
 				if (s[i].ttyp != 0 && s[i].ttyvp == 0)
 					m = 1;
 			} else if (s[i].ttyp != 0 && s[i].tdev == n)
 				m = 1;
 			if (!m)
 				continue;
 		}
 		printf ("\t%d %d:%d:%d:%d:%d\n", x, s[i].pid, s[i].ttyvp,
 			s[i].control, s[i].ttyp, s[i].tdev);
 	}
 }
 
 void
 joebarteam(int n)
 {
 	int i;
 
 	printf("%d:\n", n);
 	for (i = 0; s[i].pid; i++) {
 		int x = 0;
 		if (s[i].control == 0 ||
 		    s[i].session == 0) {
 			if (n != -1)
 				continue;
 		} else {
 			int m = 0;
 			if (n == -2) {
 				if (s[i].ttyp == 0 || s[i].ttyvp != 0)
 					m = 1;
 			} else if (s[i].ttyp == 0) {
 				if (n != -1)
 					m = 1;
 			} else if (s[i].tdev != n)
 				m = 1;
 			if (m)
 				continue;
 		}
 		printf ("\t%d %d:%d:%d:%d:%d\n", x, s[i].pid, s[i].ttyvp,
 			s[i].control, s[i].ttyp, s[i].tdev);
 	}
 }
 
 main () {
 	printf("original (netbsd)\n");
 	foo(0); foo(1); foo(2); foo(-1); foo(-2);
 	printf("cle\n");
 	bar(0); bar(1); bar(2); bar(-1); bar(-2);
 	printf("gad\n");
 	foobar(0); foobar(1); foobar(2); foobar(-1); foobar(-2);
 	printf("translated (netbsd)\n");
 	joebarteam(0); joebarteam(1); joebarteam(2); joebarteam(-1); joebarteam(-2);
 }
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 05:50:52 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > The summary of your changes includes the section:
 > 
 >     <quote "right">
 >     When printing using the command keyword, a process that has exited
 >     and has a parent that has not yet waited for the process (in other
 >     words, a zombie) is listed as ``<defunct>''.
 >     </quote>
 > 
 >     <quote "wrong">
 >     and a process which is blocked while trying to exit is listed as
 >     ``<exiting>''
 >     </quote>
 > 
 >     <cite "netbsd">
 >     If the command vector cannot be located (usually because it has
 >     not been set, as is the case of system processes and/or kernel
 >     threads) the command name is printed within square brackets.
 >     </cite>
 > 
 > What is "wrong" about what we do?  Is it just that we are different
 
 the right and wrong quotes match my ps, not the current one.
 the current ps shows defunct processes between () AFAIK,
 instead of as <defunct> per SUSv3. <existing> has been withdraw
 a long time ago (don't remember exactly, but I could find you the
 answer, at least, it is not part of 4.4BSD-Lite2 on which FreeBSD
 is based on :) so, the documentation does not match the reality.
 
 > from NetBSD?  That would be a reasonable answer, but I am wondering
 
 it was just a suggestion to show system processes between brackets
 to differentiate them from processes w/o argv0.
 
 > if there any other OS's which behave the same way.  A quick glance
 > suggests that linux might.  Any others?  Solaris, AIX, and OpenBSD
 
 yes, Tru64 :)
 
 lefevrec@spe207.testdrive.hp.com> ps ax
    PID TTY      S           TIME CMD
 1048576 ??       R <     06:51:14 [kernel idle]
 1048577 ??       SL       0:11.98 /sbin/init -a
 1048578 ??       U        0:00.00 [kproc_creator_da]
 ...
 1048654 ??       U        0:00.98 [icssvr_daemon_pe]
 1048667 ??       IW       0:00.03 /usr/sbin/esmd
 ...
 
 
 > do not seem to, but then they do not seem to show any "system
 > processes or kernel threads", so maybe that is irrelevant.
 
 [snip
 > That has nothing to do with ``<exiting>''.
 
 no, the netbsd quote has nothing do w/ <existing> :)
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosehn" <gad@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 06:04:24 +0200

 "Garance A Drosehn" <gad@FreeBSD.org> wrote:
 > A minor thing I noticed while poking around today...
 >
 > (39) ps -l
 >    UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT  TT       TIME COMMAND
 >      0  7779  1113   0  96  0  1368  864 -      R+    p2    0:00.00 ps -l
 >
 > (40)  ps-cyr -l
 >    UID   PID  PPID CPU PRI  NI   VSZ   RSS MWCHAN STAT TT       TIME COMMAND
 >      0  7780  1113   1  96   0  1432  1028 -      O+   p2    0:00.00 ps-cyr -l
 >
 > It seems that the full-updated `ps' consistently has a larger RSS...
 > (I expect that is not much of an issue).
 
 
 yes, I extend the RSS size to match VSZ one. here is why :
 
 # ops axl | grep spamd
     0 64382     1   0   4  0 28848 11264 select Ss    ??    0:15.98
 /usr/local/bin/spamd -a -c -d -r /var/run/spamd.pid (perl5.8.2)
     0 84544 74036   0  77  0  1492  808 -      R+    p1    0:00.03 grep spam
 # bps axl | grep spamd
     0 64382     1   0   4   0 28848 11264 select Ss   ??    0:15.98
 /usr/local/bin/spamd -a -c -d -r /var/run/spamd.pid (perl5.8.2)
     0 96807 74036   0  -8   0  1556   904 piperd S+   p1    0:00.04 grep spam
 
 also, nice has been extended by one since it may have a negative value.
 
 PS : ops is -current ps, bps is my "bsd" ps and psx is my "posix" ps.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Bruce Evans <bde@zeta.org.au>
To: Cyrille Lefevre <cyrille.lefevre@laposte.net>
Cc: freebsd-gnats-submit@freebsd.org,
	Garance A Drosehn <gad@freebsd.org>
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 14:12:10 +1000 (EST)

 On Tue, 22 Jun 2004, Cyrille Lefevre wrote:
 
 > "Bruce Evans" <bde@zeta.org.au> wrote:
 > > calcru() only requires sched_lock and possibly PROC_LOCK() (except
 > > in my version (*)), and both of these locks are already held in
 > > fill_kinfo_thread(), so the fix really is one-line and the only slowness
 >
 > forgot about that :)
 >
 > > is in the actual call.
 >
 > if the Giant lock isn't necessary, maybe you can get rid of it in getrusage() ?
 > not sure about exit1(), my kernel knowledge is not so deep :(
 
 I've already done this in my version of getrusage().  See the patch at the
 end.  exit1() is much more complicated.  It has to acquire and release
 Giant and other locks at various points to satisfy different locking
 requirements for different data structures.  The locked regions are
 relatively short, but this is not exactly good for performance because it
 involves lots of locking operations.  In my version, calcru() is not
 called from exit1() so the locking for it is moot there.  It basically
 requires sched_lock for accessing the current time, switchtime and the
 tick counts, and PROC_LOCK() for accessing time previous calcru() times.
 Most of it (by lines of code if not real time) only requires PROC_LOCK().
 
 > > > but, this consume too much resources, IMHO.
 > >
 > > calcru() itself consumes too much resources, but I'm not worried about
 > > this here (except see (*)) since I think fill_kinfo_thread() is mainly
 > > used for interactive purposes.
 >
 > about the consummation, I was talking about locks, not about calcru() by itself.
 > also, as Garance said :
 >
 >     "The change updates the version in the kproc_info struct that we
 >     are returning, not the system copy.  I believe that we do not
 >     need a lock for that."
 
 This is not quite correct, since accessing the previous calcru() times
 require a lock, especially for writing.  Thes are pre-process and only
 accessed in calcru(), so they don't need anyway such strong locking as
 sched locking.
 
 Removing the Giant locking in getrusage() mainly requires being careful
 about using proc locking for the previous calcru() times.  This is not
 done in -current.  My calcru() does all the necessary locking for itself
 internally, but I needed to add proc locking here to protect the copying
 of the rusage.  This locking may be insufficent for all of the fields in
 the rusage, but if so the Giant locking in -current is insufficient too.
 
 Index: kern_resource.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/kern_resource.c,v
 retrieving revision 1.140
 diff -u -2 -r1.140 kern_resource.c
 --- kern_resource.c	21 Jun 2004 17:46:27 -0000	1.140
 +++ kern_resource.c	21 Jun 2004 18:01:58 -0000
 @@ -822,41 +868,46 @@
 
  	p = td->td_proc;
 +	PROC_LOCK(p);
  	switch (uap->who) {
 
  	case RUSAGE_SELF:
 -		mtx_lock(&Giant);
 -		mtx_lock_spin(&sched_lock);
 -		calcru(p, &p->p_stats->p_ru.ru_utime, &p->p_stats->p_ru.ru_stime,
 -		    NULL);
 -		mtx_unlock_spin(&sched_lock);
  		ru = p->p_stats->p_ru;
 -		mtx_unlock(&Giant);
 +		calcru(p, &ru.ru_utime, &ru.ru_stime, NULL);
  		break;
 
  	case RUSAGE_CHILDREN:
 -		mtx_lock(&Giant);
  		ru = p->p_stats->p_cru;
 -		mtx_unlock(&Giant);
 +		calccru(p, &ru.ru_utime, &ru.ru_stime);
  		break;
 
  	default:
 +		PROC_UNLOCK(p);
  		return (EINVAL);
 -		break;
  	}
 +	PROC_UNLOCK(p);
  	return (copyout(&ru, uap->rusage, sizeof(struct rusage)));
  }
 
 [... patch truncated (has lots of unrelated changes]
 %%%
 
 Bruce

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 13:06:15 -0400

 At 5:04 AM +0200 6/22/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  >
 >>  tty_wanted = (udev_t)name[0];
 >
 >please, don't. that does not follow the code around.
 
 But it lets me avoid a lot of line-wrapping...  :-)
 
 >  > I am pretty sure the logic comes out exactly the same in
 >  > the two versions, but I want to be sure that the logic for
 >  > the TTY_REVOKE section is correct.  ...
 >
 >I've written a test program to validate my logic. I write it
 >down your logic and it is also right. however, if you dislike
 >the way I go, I propose you to go the way NetBSD go...
 
 I might do that.  I'll see how it looks once it is all indented.
 Also, thanks for the program.  I'll try to run that once I get
 back to making the kern-related changes, such as this tty one.
 
 >  > That process *was* one which had revoked a tty, but I have the
 >  > vague feeling that it should have matched some other processes
 >  > too.  Should
 >
 >so, it should only match those w/o KI_CTTY (aka the ones
 >terminated by a "-" in the tt field).
 >
 >  > that match some daemons, maybe?
 >
 >daemons are mostly matched by ps -t? (the ones w/ ?? in the
 >tt field).
 
 Okay.  That helps me know for sure if it's doing the right thing
 (at least on *my* systems! :-).  Thanks!
 
 >  > [I started out on that section just because it is a style error.
 >>  All the lines after the first one should line up with a 4-character
 >>  indent, but fixing that just made it even HARDER to read...]
 >
 >that's why I didn't follow style(9) here... to line-up conditions.
 
 But that would not be a good enough reason to break style(9).  The
 only time I break from style(9) indenting is when I am filling in
 some large array or struct (and even then Bruce often grumbles about
 it...).  If plain code is really unreadable using style(9), then I
 will usually choose to rewrite/reorganize the code.  If you are too
 eager to break style(9) for "readability", then you end up with
 every programmer writing in whatever style they consider readable.
 
 The whole point of style(9) is to make code readable by making it
 look consistent.  That goal will only work if we really do use it
 as much as possible.  (IMO)
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 13:14:12 -0400

 At 6:04 AM +0200 6/22/04, Cyrille Lefevre wrote:
 >"Garance A Drosehn" <gad@FreeBSD.org> wrote:
 >>  A minor thing I noticed while poking around today...
 >>
 >>  (39) ps -l
 >>     UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT  TT       TIME COMMAND
 >>       0  7779  1113   0  96  0  1368  864 -      R+    p2    0:00.00 ps -l
 >>
 >>  (40)  ps-cyr -l
 >>     UID   PID  PPID CPU PRI  NI   VSZ   RSS MWCHAN STAT TT       TIME COMMAND
 >  >      0  7780  1113   1  96   0  1432  1028 -      O+   p2 
 >0:00.00 ps-cyr -l
 >>
 >>  It seems that the full-updated `ps' consistently has a larger RSS...
 >>  (I expect that is not much of an issue).
 >
 >yes, I extend the RSS size to match VSZ one. here is why :
 >        [...]
 >also, nice has been extended by one since it may have a negative value.
 
 I think this is one case where you misunderstood what I meant,
 although I can see why (now that I understand what you thought
 I meant...).
 
 What I meant is that the upgraded `ps' process consistently has a
 higher *value* for RSS, compared to the present `ps' command.  In
 the above, both commands were run with the same arguments, but
 `ps-cyr' has an RSS of 1028 while the older `ps' is only 864.
 
 I do not think this is much of an issue, but it was interesting
 to notice.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 18:48:04 -0400

 At 11:50 PM +0200 6/22/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  >
 >  > What I meant is that the upgraded `ps' process consistently has a
 >>  higher *value* for RSS, compared to the present `ps' command.  In
 >>  the above, both commands were run with the same arguments, but
 >>  `ps-cyr' has an RSS of 1028 while the older `ps' is only 864.
 >>
 >>  I do not think this is much of an issue, but it was interesting
 >  > to notice.
 >
 >here are my values !
 >
 >   UID   PID  PPID CPU PRI  NI  VSZ  RSS MWCHAN STAT ...
 >
 ># ./ops -axl | grep [p]s
 >     0 32161 52884   0  76  0  1500  828   -    R+ ... ops -axl
 ># ./bps -axl | grep [p]s
 >     0 11917 57837   0  76  0  1512  880   -    O+ ... ps -axl
 
 Well, I guess that would make it even less of an issue!  :-)
 
 >I'm running i386 arch w/ the following flags :
 >
 >-O -pipe -fcaller-saves -fforce-addr -fforce-mem
 >          -funroll-loops -march=pentium-mmx
 >
 >what are you running ?
 
 For both the "release-5" ps and for my copy of your ps, I should
 be running with whatever the base-system usually uses, plus a
 whole bunch of extra warning flags.  That comes out to:
 
 cc -O -pipe  -DLAZY_PS -g
        -W -Wall -ansi -Wbad-function-cast -Wcast-align -Wcast-qual
        -Wchar-subscripts -Winline -Wmissing-prototypes
        -Wnested-externs -Wpointer-arith -Wredundant-decls
        -Wshadow -Wstrict-prototypes -Wwrite-strings -Werror
        -Wno-format-y2k -Wreturn-type -Wswitch -Wsystem-headers
 
 So, no special optimization flags.  I tend to avoid those, since
 I am compiling on multiple platforms.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: Garance A Drosehn <gad@FreeBSD.org>,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 01:27:11 +0200 (CEST)

 Hi,
 
 to help you in moving forward against my PR, here is some minor fixes
 easy to handle. the next ones will be tty changes, queue(3) and keyword.c.
 
 PS : could you remember me what is the time line for 6.x ?
 
 here is some little alignment fixes...
 
 extern.h / print.c
 ucomm : don't pad is its the last field the same way as command and arguments
 upr : scale the same way as pri.
 started : right justify - if not ki_valid
 wchan/mwchan : right justify the numeric values
 priorityr : handle PRI_ITHD ("intr")
 label : left justify -, there is no need for the initial spaces !
 	or right justify -. is the 
 
 and some other simple fixes easy to handle...
 
 ps.c
 saveuser : defunct and [system proc] added, malloc check added.
 pscomp : also sort by thread id for matching process ids.
 usage : is missing -c and -e !
 
 below, there is some kernel fixes.
 
 Index: extern.h
 ===================================================================
 RCS file: /home/ncvs/src/bin/ps/extern.h,v
 retrieving revision 1.35
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.35 extern.h
 --- extern.h	22 Jun 2004 02:15:58 -0000	1.35
 +++ extern.h	22 Jun 2004 13:27:30 -0000
 @@ -82,6 +82,7 @@
  void	 tname(KINFO *, VARENT *);
  void	 ucomm(KINFO *, VARENT *);
  void	 uname(KINFO *, VARENT *);
 +void	 upr(KINFO *, VARENT *);
  void	 vsize(KINFO *, VARENT *);
  void	 wchan(KINFO *, VARENT *);
  __END_DECLS
 Index: keyword.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/ps/keyword.c,v
 retrieving revision 1.68
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.68 keyword.c
 --- keyword.c	20 Jun 2004 23:40:54 -0000	1.68
 +++ keyword.c	22 Jun 2004 21:52:07 -0000
 @@ -197,8 +197,7 @@
  		0},
  	{"uid", "UID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_uid), UINT,
  		UIDFMT, 0},
 -	{"upr", "UPR", NULL, 0, kvar, NULL, 3, KOFF(ki_pri.pri_user), UCHAR,
 -		"d", 0},
 +	{"upr", "UPR", NULL, 0, upr, NULL, 3, 0, CHAR, NULL, 0},
  	{"uprocp", "UPROCP", NULL, 0, kvar, NULL, 8, KOFF(ki_paddr), KPTR,
  		"lx", 0},
  	{"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR,
 Index: print.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/ps/print.c,v
 retrieving revision 1.88
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.88 print.c
 --- print.c	21 Jun 2004 16:53:11 -0000	1.88
 +++ print.c	22 Jun 2004 22:34:03 -0000
 @@ -64,6 +64,11 @@
  
  #define	ps_pgtok(a)	(((a) * getpagesize()) / 1024)
  
 +static double	getpmem(KINFO *);
 +static void	printval(void *, VAR *v);
 +
 +static const char	defunct[] = "<defunct>";
 +
  void
  printheader(void)
  {
 @@ -180,7 +185,10 @@
  	VAR *v;
  
  	v = ve->var;
 -	(void)printf("%-*s", v->width, k->ki_p->ki_comm);
 +	if (ve->next == NULL)		/* last field, don't pad */
 +		(void)printf("%s", k->ki_p->ki_comm);
 +	else
 +		(void)printf("%-*s", v->width, k->ki_p->ki_comm);
  }
  
  void
 @@ -265,13 +273,24 @@
  	(void)printf("%-*s", v->width, buf);
  }
  
 +#define scalepri(x)	((x) - PZERO)
 +
  void
  pri(KINFO *k, VARENT *ve)
  {
  	VAR *v;
  
  	v = ve->var;
 -	(void)printf("%*d", v->width, k->ki_p->ki_pri.pri_level - PZERO);
 +	(void)printf("%*d", v->width, scalepri(k->ki_p->ki_pri.pri_level));
 +}
 +
 +void
 +upr(KINFO *k, VARENT *ve)
 +{
 +	VAR *v;
 +
 +	v = ve->var;
 +	(void)printf("%*d", v->width, scalepri(k->ki_p->ki_pri.pri_user));
  }
  
  void
 @@ -384,7 +403,7 @@
  
  	v = ve->var;
  	if (!k->ki_valid) {
 -		(void)printf("%-*s", v->width, "-");
 +		(void)printf("%*s", v->width, "-");
  		return;
  	}
  	if (use_ampm < 0)
 @@ -446,8 +465,7 @@
  			(void)printf("%-*.*s", v->width, v->width,
  			    k->ki_p->ki_wmesg);
  		else
 -			(void)printf("%-*lx", v->width,
 -			    (long)k->ki_p->ki_wchan);
 +			(void)printf("%*lx", v->width, (long)k->ki_p->ki_wchan);
  	} else
  		(void)printf("%-*s", v->width, "-");
  }
 @@ -476,8 +494,7 @@
  			(void)printf("%-*.*s", v->width, v->width,
  			    k->ki_p->ki_wmesg);
  		else
 -			(void)printf("%-*lx", v->width,
 -			    (long)k->ki_p->ki_wchan);
 +			(void)printf("%*lx", v->width, (long)k->ki_p->ki_wchan);
  	} else if (k->ki_p->ki_kiflag & KI_LOCKBLOCK) {
  		if (k->ki_p->ki_lockname[0]) {
  			(void)printf("%-*.*s", v->width, v->width,
 @@ -655,6 +672,9 @@
  	class = lpri->pri_class;
  	level = lpri->pri_level;
  	switch (class) {
 +	case PRI_ITHD:
 +		strncpy(str, "intr", sizeof(str));
 +		break;
  	case PRI_REALTIME:
  		snprintf(str, sizeof(str), "real:%u", level);
  		break;
 @@ -783,7 +803,7 @@
  		(void)printf("%-*s", v->width, string);
  		free(string);
  	} else
 -		(void)printf("%-*s", v->width, "  -");
 +		(void)printf("%-*s", v->width, "-");
  	return;
  }
  
 Index: ps.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/ps/ps.c,v
 retrieving revision 1.99
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.99 ps.c
 --- ps.c	20 Jun 2004 21:25:10 -0000	1.99
 +++ ps.c	22 Jun 2004 22:32:19 -0000
 @@ -977,19 +977,28 @@
  	/*
  	 * save arguments if needed
  	 */
 -	if (needcomm && (UREADOK(ki) || (ki->ki_p->ki_args != NULL))) {
 -		ki->ki_args = strdup(fmt(kvm_getargv, ki, ki->ki_p->ki_comm,
 -		    MAXCOMLEN));
 -	} else if (needcomm) {
 -		asprintf(&ki->ki_args, "(%s)", ki->ki_p->ki_comm);
 +	if (needcomm) {
 +		if (ki->ki_p->ki_stat == SZOMB)
 +			asprintf(&ki->ki_args, "<defunct>");
 +		else if (ki->ki_p->ki_flag & P_SYSTEM)
 +			asprintf(&ki->ki_args, "[%s]", ki->ki_p->ki_comm);
 +		else if (UREADOK(ki) || ki->ki_p->ki_args)
 +			ki->ki_args = strdup(fmt(kvm_getargv, ki, ki->ki_p->ki_comm,
 +			    MAXCOMLEN));
 +		else
 +			asprintf(&ki->ki_args, "(%s)", ki->ki_p->ki_comm);
 +		if (!ki->ki_args)
 +			errx(1, "malloc failed");
  	} else {
  		ki->ki_args = NULL;
  	}
 -	if (needenv && UREADOK(ki)) {
 -		ki->ki_env = strdup(fmt(kvm_getenvv, ki, (char *)NULL, 0));
 -	} else if (needenv) {
 -		ki->ki_env = malloc(3);
 -		strcpy(ki->ki_env, "()");
 +	if (needenv) {
 +		if (UREADOK(ki))
 +			ki->ki_env = strdup(fmt(kvm_getenvv, ki, (char *)NULL, 0));
 +		else
 +			asprintf(&ki->ki_env, "()");
 +		if (!ki->ki_env)
 +			errx(1, "malloc failed");
  	} else {
  		ki->ki_env = NULL;
  	}
 @@ -1025,7 +1034,9 @@
  		DIFF_RETURN(ka, kb, ki_p->ki_tdev);
  	}
  
 +	/* PID's and TID's (threads) are sorted in ascending order. */
  	DIFF_RETURN(ka, kb, ki_p->ki_pid);
 +	DIFF_RETURN(ka, kb, ki_p->ki_tid);
  	return (0);
  }
  #undef DIFF_RETURN
 @@ -1133,7 +1144,7 @@
  static void
  usage(void)
  {
 -#define	SINGLE_OPTS	"[-aC" OPT_LAZY_f "HhjlmrSTuvwXxZ]"
 +#define	SINGLE_OPTS	"[-aCce" OPT_LAZY_f "HhjlmrSTuvwXxZ]"
  
  	(void)fprintf(stderr, "%s\n%s\n%s\n%s\n",
  	    "usage: ps " SINGLE_OPTS " [-G gid[,gid]] [-O|o fmt]",
 
 src/lib/libkvm/kvm_proc.c :
 	conditionnal fix
 	strncpy -> strlcpy
 src/sys/kern/kern_proc.c
 	default -> EINVAL
 
 Index: src/lib/libkvm/kvm_proc.c
 ===================================================================
 RCS file: /home/ncvs/src/lib/libkvm/kvm_proc.c,v
 retrieving revision 1.76
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.76 kvm_proc.c
 --- src/lib/libkvm/kvm_proc.c	19 Jun 2004 14:08:10 -0000	1.76
 +++ src/lib/libkvm/kvm_proc.c	22 Jun 2004 14:34:04 -0000
 @@ -128,7 +128,7 @@
  				    TAILQ_FIRST(&proc.p_threads));
  				return (-1);
  			}
 -			if (proc.p_flag & P_SA == 0) {
 +			if ((proc.p_flag & P_SA) == 0) {
  				if (KREAD(kd,
  				    (u_long)TAILQ_FIRST(&proc.p_ksegrps),
  				    &mkg)) {
 @@ -328,10 +328,8 @@
  				continue;
  			break;
  		}
 -		if (proc.p_comm[0] != 0) {
 -			strncpy(kp->ki_comm, proc.p_comm, MAXCOMLEN);
 -			kp->ki_comm[MAXCOMLEN] = 0;
 -		}
 +		if (proc.p_comm[0] != 0)
 +			strlcpy(kp->ki_comm, proc.p_comm, MAXCOMLEN);
  		(void)kvm_read(kd, (u_long)proc.p_sysent, (char *)&sysent,
  		    sizeof(sysent));
  		(void)kvm_read(kd, (u_long)sysent.sv_name, (char *)&svname,
 Index: src/sys/kern/kern_proc.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
 retrieving revision 1.211
 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.211 kern_proc.c
 --- src/sys/kern/kern_proc.c	20 Jun 2004 22:17:22 -0000	1.211
 +++ src/sys/kern/kern_proc.c	22 Jun 2004 14:40:29 -0000
 @@ -1055,9 +1055,15 @@
  			case KERN_PROC_PROC:
  				break;
  
 -			default:
 +			case KERN_PROC_ALL:
 +				/* no filtering */
  				break;
  
 +			default:
 +				PROC_UNLOCK(p);
 +				sx_sunlock(&allproc_lock);
 +				return(EINVAL);
 +
  			}
  
  			error = sysctl_out_proc(p, req, flags | doingzomb);
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: Garance A Drosehn <gad@FreeBSD.org>,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 02:04:11 +0200 (CEST)

 Hi, this patch is relative to the last fix sent a few minutes ago :)
 
 struct varent -> VARENT
 struct kinfo -> KINFO
 -> queue(3)
 
 diff -u /tmp/src/bin/ps/extern.h /usr/src/bin/ps/extern.h
 --- /tmp/src/bin/ps/extern.h	Wed Jun 23 01:29:49 2004
 +++ /usr/src/bin/ps/extern.h	Wed Jun 23 01:47:39 2004
 @@ -30,17 +30,12 @@
   * $FreeBSD$
   */
  
 -struct kinfo;
 -struct nlist;
 -struct var;
 -struct varent;
 -
  extern fixpt_t ccpu;
  extern int cflag, eval, fscale, nlistread, rawcpu;
  extern unsigned long mempages;
  extern time_t now;
  extern int sumrusage, termwidth, totwidth;
 -extern VARENT *vhead;
 +extern VARLIST varlist;
  
  __BEGIN_DECLS
  void	 arguments(KINFO *, VARENT *);
 diff -u /tmp/src/bin/ps/keyword.c /usr/src/bin/ps/keyword.c
 --- /tmp/src/bin/ps/keyword.c	Wed Jun 23 01:29:49 2004
 +++ /usr/src/bin/ps/keyword.c	Wed Jun 23 01:54:08 2004
 @@ -235,7 +235,6 @@
  void
  parsefmt(const char *p, int user)
  {
 -	static struct varent *vtail;
  	char *tempstr, *tempstr1;
  
  #define		FMTSEP	" \t,\n"
 @@ -243,7 +242,7 @@
  	while (tempstr && *tempstr) {
  		char *cp, *hp;
  		VAR *v;
 -		struct varent *vent;
 +		VARENT *vent;
  
  		/*
  		 * If an item contains an equals sign, it specifies a column
 @@ -270,7 +269,7 @@
  			if (vent != NULL)
  				continue;
  		}
 -		if ((vent = malloc(sizeof(struct varent))) == NULL)
 +		if ((vent = malloc(sizeof(VARENT))) == NULL)
  			errx(1, "malloc failed");
  		vent->header = v->header;
  		if (hp) {
 @@ -282,16 +281,10 @@
  		if (vent->var == NULL)
  			errx(1, "malloc failed");
  		memcpy(vent->var, v, sizeof(*vent->var));
 -		vent->next = NULL;
 -		if (vhead == NULL)
 -			vhead = vtail = vent;
 -		else {
 -			vtail->next = vent;
 -			vtail = vent;
 -		}
 +		STAILQ_INSERT_TAIL(&varlist, vent, list);
  	}
  	free(tempstr1);
 -	if (!vhead) {
 +	if (STAILQ_EMPTY(&varlist)) {
  		warnx("no valid keywords; valid keywords:");
  		showkey();
  		exit(1);
 diff -u /tmp/src/bin/ps/print.c /usr/src/bin/ps/print.c
 --- /tmp/src/bin/ps/print.c	Wed Jun 23 01:29:49 2004
 +++ /usr/src/bin/ps/print.c	Wed Jun 23 01:40:42 2004
 @@ -73,27 +73,23 @@
  printheader(void)
  {
  	VAR *v;
 -	struct varent *vent;
 -	int allempty;
 +	VARENT *vent;
  
 -	allempty = 1;
 -	for (vent = vhead; vent; vent = vent->next)
 -		if (*vent->header != '\0') {
 -			allempty = 0;
 +	STAILQ_FOREACH(vent, &varlist, list)
 +		if (*vent->header)
  			break;
 -		}
 -	if (allempty)
 +	if (!vent)
  		return;
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
  		v = vent->var;
  		if (v->flag & LJUST) {
 -			if (vent->next == NULL)	/* last one */
 +			if (STAILQ_NEXT(vent, list) == NULL)	/* last one */
  				(void)printf("%s", vent->header);
  			else
  				(void)printf("%-*s", v->width, vent->header);
  		} else
  			(void)printf("%*s", v->width, vent->header);
 -		if (vent->next != NULL)
 +		if (STAILQ_NEXT(vent, list) != NULL)
  			(void)putchar(' ');
  	}
  	(void)putchar('\n');
 @@ -110,7 +106,7 @@
  	if ((vis_args = malloc(strlen(k->ki_args) * 4 + 1)) == NULL)
  		errx(1, "malloc failed");
  	strvis(vis_args, k->ki_args, VIS_TAB | VIS_NL | VIS_NOSLASH);
 -	if (ve->next == NULL) {
 +	if (STAILQ_NEXT(ve, list) == NULL) {
  		/* last field */
  		if (termwidth == UNLIMITED) {
  			(void)printf("%s", vis_args);
 @@ -136,7 +132,7 @@
  
  	v = ve->var;
  	if (cflag) {
 -		if (ve->next == NULL)	/* last field, don't pad */
 +		if (STAILQ_NEXT(ve, list) == NULL) /* last field, don't pad */
  			(void)printf("%s", k->ki_p->ki_comm);
  		else
  			(void)printf("%-*s", v->width, k->ki_p->ki_comm);
 @@ -152,7 +148,7 @@
  	} else
  		vis_env = NULL;
  
 -	if (ve->next == NULL) {
 +	if (STAILQ_NEXT(ve, list) == NULL) {
  		/* last field */
  		if (termwidth == UNLIMITED) {
  			if (vis_env)
 @@ -185,7 +181,7 @@
  	VAR *v;
  
  	v = ve->var;
 -	if (ve->next == NULL)		/* last field, don't pad */
 +	if (STAILQ_NEXT(ve, list) == NULL)	/* last field, don't pad */
  		(void)printf("%s", k->ki_p->ki_comm);
  	else
  		(void)printf("%-*s", v->width, k->ki_p->ki_comm);
 diff -u /tmp/src/bin/ps/ps.c /usr/src/bin/ps/ps.c
 --- /tmp/src/bin/ps/ps.c	Wed Jun 23 01:29:49 2004
 +++ /usr/src/bin/ps/ps.c	Wed Jun 23 01:35:19 2004
 @@ -47,7 +47,7 @@
  #endif
  
  #include <sys/cdefs.h>
 -__FBSDID("$FreeBSD$");
 +__FBSDID("$FreeBSD: src/bin/ps/ps.c,v 1.98 2004/06/01 23:27:11 gad Exp $");
  
  #include <sys/param.h>
  #include <sys/proc.h>
 @@ -98,7 +98,7 @@
  int	 termwidth;		/* Width of the screen (0 == infinity). */
  int	 totwidth;		/* Calculated-width of requested variables. */
  
 -struct varent *vhead;
 +VARLIST varlist = STAILQ_HEAD_INITIALIZER(varlist);
  
  static int	 forceuread = DEF_UREAD; /* Do extra work to get u-area. */
  static kvm_t	*kd;
 @@ -167,7 +167,7 @@
  	struct listinfo ruidlist, sesslist, ttylist, uidlist;
  	struct kinfo_proc *kp;
  	KINFO *next_KINFO;
 -	struct varent *vent;
 +	VARENT *vent;
  	struct winsize ws;
  	const char *nlistf, *memf;
  	char *cols;
 @@ -600,9 +600,9 @@
  	 * For each process, call each variable output function.
  	 */
  	for (i = lineno = 0; i < nkept; i++) {
 -		for (vent = vhead; vent; vent = vent->next) {
 +		STAILQ_FOREACH(vent, &varlist, list) {
  			(vent->var->oproc)(&kinfo[i], vent);
 -			if (vent->next != NULL)
 +			if (STAILQ_NEXT(vent, list) != NULL)
  				(void)putchar(' ');
  		}
  		(void)putchar('\n');
 @@ -884,9 +884,9 @@
  VARENT *
  find_varentry(VAR *v)
  {
 -	struct varent *vent;
 +	VARENT *vent;
  
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
  		if (strcmp(vent->var->name, v->name) == 0)
  			return vent;
  	}
 @@ -896,10 +896,10 @@
  static void
  scanvars(void)
  {
 -	struct varent *vent;
 +	VARENT *vent;
  	VAR *v;
  
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
  		v = vent->var;
  		if (v->flag & DSIZ) {
  			v->dwidth = v->width;
 @@ -915,11 +915,11 @@
  static void
  dynsizevars(KINFO *ki)
  {
 -	struct varent *vent;
 +	VARENT *vent;
  	VAR *v;
  	int i;
  
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
  		v = vent->var;
  		if (!(v->flag & DSIZ))
  			continue;
 @@ -934,11 +934,11 @@
  static void
  sizevars(void)
  {
 -	struct varent *vent;
 +	VARENT *vent;
  	VAR *v;
  	int i;
  
 -	for (vent = vhead; vent; vent = vent->next) {
 +	STAILQ_FOREACH(vent, &varlist, list) {
  		v = vent->var;
  		i = strlen(vent->header);
  		if (v->width < i)
 diff -u /tmp/src/bin/ps/ps.h /usr/src/bin/ps/ps.h
 --- /tmp/src/bin/ps/ps.h	Sun Jun 20 23:25:10 2004
 +++ /usr/src/bin/ps/ps.h	Wed Jun 23 01:45:02 2004
 @@ -30,6 +30,8 @@
   * $FreeBSD$
   */
  
 +#include <sys/queue.h>
 +
  #define	UNLIMITED	0	/* unlimited terminal width */
  enum type { CHAR, UCHAR, SHORT, USHORT, INT, UINT, LONG, ULONG, KPTR, PGTOK };
  
 @@ -43,9 +45,11 @@
  } KINFO;
  
  /* Variables. */
 +typedef STAILQ_HEAD(varlist, varent) VARLIST;
 +
  typedef struct varent {
 +	STAILQ_ENTRY(varent) list;
  	const char *header;
 -	struct varent *next;
  	struct var *var;
  } VARENT;
  
 @@ -60,9 +64,9 @@
  #define	INF127	0x10		/* values >127 displayed as 127 */
  	u_int	flag;
  				/* output routine */
 -	void	(*oproc)(struct kinfo *, struct varent *);
 +	void	(*oproc)(KINFO *, VARENT *);
  				/* sizing routine*/
 -	int	(*sproc)(struct kinfo *);
 +	int	(*sproc)(KINFO *);
  	short	width;		/* printing width */
  	/*
  	 * The following (optional) elements are hooks for passing information
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 20:41:48 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >Hi,
 >
 >to help you in moving forward against my PR, here is some
 >minor fixes easy to handle. the next ones will be tty
 >changes, queue(3) and keyword.c.
 
 I will look into these, and maybe get some of them in tonight.
 (except that I do not plan to do any kern-related updates
 this week).
 
 (I decided to take a vacation day from work so that I could
 get more of this `ps'-related work done before I show up at
 a FreeBSD developers meeting in Boston next week...).
 
 For the "tty" changes, only include the changes which do not
 depend on changes to kern_proc or kvm_proc.  It just takes
 me too long to test kern-related changes.  However, it would
 be nice to get in the matching for "ttyp0" in addition to
 "p0" and "/dev/ttyp0".
 
 queue(3)-related changes would probably be fine.
 
 I'm not sure what you intend for keyword.c, but it might be
 best to put that off for the moment.  Since I have not looked
 too closely at the changes in that file, I do not know whether
 I would want to commit whatever you plan to do (unless you
 mean "using queue(3) in keyword.c", in which case that is fine).
 
 >PS : could you remind me what is the time line for 6.x ?
 
 The last I heard, I think we were expecting to make a code-
 freeze on 5.2-current sometime in July.  This would lead up
 to 5.3-release happening in August, with the creation of
 6.x-current happening at about the same time.
 
 Once 5.3-release becomes "the stable branch", we will have
 less flexibility in making user-visible *changes*.  We can
 always add more options, of course.  But we would not want to
 do something really visible (such as changing the order of
 columns in -j, for instance) once that is a stable branch.
 
 We can still change things like the number-of-blanks between
 columns, in my opinion, because people really shouldn't be
 depending on that anyway.  But some of the changes that we
 have been discussing would be pretty user-visible, so and I
 want to get those done before the code-freeze starts.
 
 [But that timetable is not finalized yet.  It could all
 change at the FreeBSD developers meeting in Boston...]
 
 >here is some little alignment fixes...
   [...]
 >label : left justify -, there is no need for the initial spaces !
 >	or right justify -. is the
 
 I deliberately put those spaces there.  I want to leave them
 there (at least for now) unless they cause some problem.
 
 >and some other simple fixes easy to handle...
 >
 >ps.c
 >saveuser : defunct and [system proc] added, malloc check added.
 >pscomp : also sort by thread id for matching process ids.
 >usage : is missing -c and -e !
 
 Seems to me there was some reason that -e was not in the
 usage() message.  I will leave it out for now.  However,
 the -c should certainly be there!  Probably a typo on my
 part when I made the OPT_LAZY_f change.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Cyrille Lefevre <cyrille.lefevre@laposte.net>
To: Garance A Drosehn <gad@FreeBSD.org>,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 03:22:26 +0200 (CEST)

 Hi, here is the user lever tty related changes since you are
 currently working on the kernel related ones (the netbsd way
 I suppose ? :).
 
 print.c
 	related to one of the last patch I sent, defunct is not needed here.
 ps.c
 	_PATH_CONSOLE -> _PATH_CONSOLECTL, strdup not need here
 	-t - and -t ? added.
 	-t ttyp0 added.
 pathnames.h
 	new file
 	how about to add _PATH_CONSOLECTL in <paths.h> instead ?
 
 diff -u /tmp/src/bin/ps/print.c /usr/src/bin/ps/print.c
 --- /tmp/src/bin/ps/print.c	Wed Jun 23 01:59:30 2004
 +++ /usr/src/bin/ps/print.c	Wed Jun 23 02:11:58 2004
 @@ -67,8 +67,6 @@
  static double	getpmem(KINFO *);
  static void	printval(void *, VAR *v);
  
 -static const char	defunct[] = "<defunct>";
 -
  void
  printheader(void)
  {
 diff -u /tmp/src/bin/ps/ps.c /usr/src/bin/ps/ps.c
 --- /tmp/src/bin/ps/ps.c	Wed Jun 23 01:59:30 2004
 +++ /usr/src/bin/ps/ps.c	Wed Jun 23 02:50:38 2004
 @@ -72,6 +72,7 @@
  #include <unistd.h>
  
  #include "ps.h"
 +#include "pathnames.h"
  
  #define	W_SEP	" \t"		/* "Whitespace" list separators */
  #define	T_SEP	","		/* "Terminate-element" list separators */
 @@ -710,25 +711,39 @@
  	struct stat sb;
  	char pathbuf[PATH_MAX];
  
 -	if (strcmp(elem, "co") == 0)
 -		ttypath = strdup(_PATH_CONSOLE);
 -	else if (*elem == '/')
 +	switch (*elem) {
 +	case '?':
 +	case '-':
 +		ttypath = NULL;
 +		sb.st_rdev = *elem == '?' ? KERN_PROC_TTY_NODEV :
 +		    KERN_PROC_TTY_REVOKE;
 +		break;
 +	case '/':
  		ttypath = elem;
 -	else {
 -		strlcpy(pathbuf, _PATH_TTY, sizeof(pathbuf));
 +		break;
 +	case 'c':
 +		if (strcmp(elem, "co") == 0) {
 +			ttypath = _PATH_CONSOLECTL;
 +			break;
 +		}
 +		/* FALLTHROUGH */
 +	default:
 +		strlcpy(pathbuf, !strncmp(elem, "tty", 3) ? _PATH_DEV :
 +		    _PATH_TTY, sizeof(pathbuf));
  		strlcat(pathbuf, elem, sizeof(pathbuf));
  		ttypath = pathbuf;
  	}
 -
 -	if (stat(ttypath, &sb) == -1) {
 -		warn("%s", ttypath);
 -		optfatal = 1;
 -		return (0);
 -	}
 -	if (!S_ISCHR(sb.st_mode)) {
 -		warn("%s: Not a terminal", ttypath);
 -		optfatal = 1;
 -		return (0);
 +	if (ttypath) {
 +		if (stat(ttypath, &sb) == -1) {
 +			warn("%s", ttypath);
 +			optfatal = 1;
 +			return (0);
 +		}
 +		if (!S_ISCHR(sb.st_mode)) {
 +			warn("%s: Not a terminal", ttypath);
 +			optfatal = 1;
 +			return (0);
 +		}
  	}
  	if (inf->count >= inf->maxcount)
  		expand_list(inf);
 --- /dev/null	Wed Jun 23 02:55:41 2004
 +++ pathnames.h	Wed Jun 23 02:50:03 2004
 @@ -0,0 +1,32 @@
 +/*
 + * Copyright (c) 2004 Cyrille Lefevre <Cyrille.Lefevre@laposte.net>
 + * All rights reserved.
 + *
 + * Redistribution and use in source and binary forms, with or without
 + * modification, are permitted provided that the following conditions
 + * are met:
 + * 1. Redistributions of source code must retain the above copyright
 + *    notice, this list of conditions and the following disclaimer.
 + * 2. Redistributions in binary form must reproduce the above copyright
 + *    notice, this list of conditions and the following disclaimer in the
 + *    documentation and/or other materials provided with the distribution.
 + * 4. The name of the authors and contributors may not be used to endorse
 + *    or promote products derived from this software without specific
 + *    prior written permission.
 + *
 + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 + * SUCH DAMAGE.
 + *
 + * $FreeBSD$
 + */
 +
 +#define	_PATH_CONSOLECTL	"/dev/consolectl"
 
 
 Cyrille Lefevre
 -- 
 mailto:cyrille.lefevre@laposte.net

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 22:11:44 -0400

 At 3:13 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >
 >fields are usually right or left justified. I think it would
 >be left justified to make the output easy to read.
 >
 >PS: I don't know what is the content of the label field, so,
 >don't care about the following example :
 >
 >LABEL PID COMMAND
 >xx    123 sh
 >   -   123 sh
 >xxxxx 123 sh
 >
 >vs.
 >
 >LABEL PID COMMAND
 >xx    123 sh
 >-     123 sh
 >xxxxx 123 sh
 
 The thing for me is that I do not know enough about MAC labels,
 either.  For all I know "-" might be a valid label, so I wanted
 to be sure that "no label" does not look the same as "a valid
 label which happens to be '-'".
 
 If we find that it was dumb for me to worry about that, then we
 can always remove the blanks.  But the above version is the one
 that Robert Watson looked at (after I committed it...), and he
 did send me a message saying that the change looked good to him.
 
 (he has not replied to a follow-up message that I sent to him
 about something else, so I expect he is very busy with other
 matters...)
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 22:29:11 -0400

 At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >Hi, here is the user lever tty related changes since you are
 >currently working on the kernel related ones (the netbsd way
 >I suppose ? :).
 
 I have no plans on doing any kern-related changes this week.
 Those plans will not change unless I get some of the more
 important `ps'-level updates committed, or if it turns out
 that I introduced some new bug(s) with the kern-related
 changes that I recently committed.
 
 Sorry about that, but I just have to concentrate on one area
 at a time here, and I can make much faster progress at the
 `ps'-level than at the kern-level updates.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 22:37:23 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >  usage : is missing -c and -e !
 
 One thing I HOPED to get done today is the update I intend to
 install for handling format-options.  This is the part of what
 I was working on which was similar to the change you described
 as:
 
        output is formatted more intelligently when combining
        options such as -j, -l, -s, -u and -v.  Format strings
        are combined instead of being concatenated.  So, field
        are always in the same place.
 
        old way :
        $ ps -lu
        UID   PID  PPID CPU PRI NI  VSZ  RSS MWCHAN  STAT  TT
                      ... TIME COMMAND USER %CPU %MEM STARTED
        $ps -ul
        USER  PID  %CPU %MEM  VSZ  RSS  TT  STAT  STARTED
                      ... TIME COMMAND UID  PPID CPU PRI NI MWCHAN
 
        new way :
        $ ps -lu # or ps -ul
        USER  UID  PID  PPID CPU PRI  NI %CPU %MEM VSZ RSS
                      ... MWCHAN TT STAT STARTED TIME COMMAND
 
 I had seen some of the same problems you saw, but I first noticed
 them as really bad interactions between -Z, -O, -o, and all the
 other options.  After I read your description, I thought "gee, I
 can do that with only a bit more shuffling around".  However,
 once I got to the final result I really did not like it.  I kept
 thinking:
      But *why* should `-uv' be the same as `-vu'?
      After all, '-o user,uid' is not the same as `-o uid,user'
      And `-rm' is not the same as `-mr'...
 
 I ran into this debate (with myself) when trying to decide what
 the "ideal order" should be for any particular combination.  While
 I could come up with some order that *I* liked, there was no way I
 could say why `ps' *must* use that order I liked.  I could not
 defend it against anyone who happened to like some other order for
 the same combination of options.
 
 So, I rewrote shuffled my update around again, and came up with
 something that is somewhat between your original idea and my
 original idea.  I am confident that my present result is better
 than my original idea.  However, I do not know if you will be
 quite as happy with it as I am.
 
 At this point it seems to be working the way I expect it to, for
 the examples I have tested it with.  The fact that you happened
 to mention `-c' was a useful coincidence, though.  I had not done
 any tests with `-c', and now that I have I see that I got that
 part wrong!  It was because I had blindly decided to use "args"
 instead of "command" as the option-name to add.  I always assumed
 that those two were exactly the same, but now I see that they are
 not.  I switched back to using "command", and that fixed it.  Now
 I just need to rename a few variables and rewrite a few comments
 to match.
 
 I HOPE to have all that done and "fairly well-tested" tonight, in
 which case I will post that update as a reply to this PR.  I will
 then do a bit more testing with it over the next day or two to
 make sure I have not missed any other cases.  And then I will
 probably commit something pretty close to what I have.
 
 [but I have not completely tested -Oo yet --and right this second
 it occurs to me that my present code will probably not work right
 if either of those are specified multiple times, and if any but
 the last one includes a "=header" part...  Ugh!]
 
 But at least in my present version:
        (47)  ps-rel5 -ul
        USER   UID   PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED
                       ... TIME  PPID CPU PRI NI MWCHAN COMMAND
        (48)  ps-rel5 -lu
          UID USER   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT
                       ... TT  TIME %CPU %MEM STARTED COMMAND
 
 The strategy when combining multiple format-groups is basically:
     a) combine everything that is before the "pid" columns.
     b) if Z is specified, add the "label" column
     c) add the "pid" column
     d) combine everything that is after the "pid" columns, ...
     e) except that "comm" or "command" is always moved to
        the last column.
 
 That probably sounds weird, but it seems to work well in practice,
 and I can defend *why* I picked that set of rules instead of any
 other set.  And it is pretty easy to add more format-groups to
 the code, if we want to.  It is just a matter of adding three
 #define's, and another 'case' section in the switch statement.
 
 Furthermore, I intend to add a sentence to the man page, which
 will say something like
     "If you *need* some specific and constant order for
      the columns, then ALWAYS use `-o' to specify the
      EXACT order that you want!"
 
 So, I probably still have to do something with -o and -O, but
 at the moment my update actually reduces the size of /bin/ps:
 
      (51)  ls -l /bin/ps /bin/ps-rel5
      -r-xr-xr-x  1 root  wheel  31328 Jun 22 18:43 /bin/ps
      -r-xr-xr-x  1 root  wheel  31000 Jun 22 21:45 /bin/ps-rel5
 
 "ps-rel5" is my testing version...
 
 However, I might move this change aside for a little while, and
 commit some of the changes you sent in your earlier messages...
 Ironically I probably would have sent it out already, if was not
 for you mentioning `-c'...
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: Cyrille Lefevre <cyrille.lefevre@laposte.net>,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 22:50:00 -0400

 At 2:40 AM +0000 6/23/04, Garance A Drosihn wrote:
 >
 >  The strategy when combining multiple format-groups is basically:
 >      a) combine everything that is before the "pid" columns.
 >      b) if Z is specified, add the "label" column
 >      c) add the "pid" column
    -->
 >      d) combine everything that is after the "pid" columns, ...
 >      e) except that "comm" or "command" is always moved to
 >         the last column.
 
 I skipped over a step there.  Between "c" and "d" is another
 important step:
        c2) add all options from -o and -O
 
 There are a few other details I have not mentioned, but those
 should be clear enough in the update (once I finish it!).
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: <freebsd-gnats-submit@freebsd.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 02:14:43 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 11:50 PM +0200 6/22/04, Cyrille Lefevre wrote:
 [snip]
 > >here are my values !
 > >
 > >   UID   PID  PPID CPU PRI  NI  VSZ  RSS MWCHAN STAT ...
 > >
 > ># ./ops -axl | grep [p]s
 > >     0 32161 52884   0  76  0  1500  828   -    R+ ... ops -axl
 > ># ./bps -axl | grep [p]s
 > >     0 11917 57837   0  76  0  1512  880   -    O+ ... ps -axl
 > 
 > Well, I guess that would make it even less of an issue!  :-)
 
 [snip]
 
 using "-O -pipe" only, RSS comes down !
 
 # ./ops -axl | grep [p]s
     0 10889 52884   0  76  0  1504  800 -      R+    p0    0:00.05 ./ops -axl
 # ./bps -axl | grep [p]s
     0  3856 57837   0  76   0  1516   852 -      O+   p2    0:00.05 ./ps -axl
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Tue, 22 Jun 2004 22:30:13 -0400

 At 3:13 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >  > Seems to me there was some reason that -e was not in the
 >
 >I don't see why, -e is an option which is well documented
 >and which has always existed, so, there is no reason to get
 >rid of it from the usage string.
 
 I do not remember at the moment, and I certainly do not think
 this is important to change (IF it even needs to be changed)
 right now.  It just is not important.  I do remember noticing
 that -e was missing from usage(), and I remember deciding that
 it was just as well to leave it out.
 
 Sigh.  I guess I should try to remember why I thought that...
 
 ...Okay.  On my present 5.x-system, when running from root, a
 `ps -e' prints out exactly the same thing as `ps'.  This is
 probably connected to some sysctl-based security setting, but
 if the *default* system configuration for *root* does not print
 out anything for `-e', then I felt there was no reason that we
 should confuse users by listing a do-nothing option in the
 usage() message.  We also do not explicitly list or document
 the `-g' option -- because it is a do-nothing option.
 
 I have no intention of pursing this any further right now.  It
 is not critical to anything.  We can revisit the question after
 we have run out of more useful updates to `ps'.  As I remember
 it, the last time I looked into this I was much more inclined
 to remove `-e' from the man page, than to add it to usage().
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 08:47:55 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >
 >here is some little alignment fixes...
 >
 >started : right justify - if not ki_valid
 
 I am not sure that we should change that.  And if we should change
 it, then we should also change lstarted.  I am a bit tired right
 now, so maybe we can revisit this when I am more awake.
 
 >priorityr : handle PRI_ITHD ("intr")
 
 It makes sense to add the case for PRI_ITHD, but why not include
 the value of "level"?   I.e., why did you go with:
 	strncpy(str, "intr", sizeof(str));
 instead of:
 	snprintf(str, sizeof(str), "intr:%u", level);
 ?
 
 >and some other simple fixes easy to handle...
 
 I have committed some of these.  I will look at the rest when I
 get back in later today.
 
 Minor note:  When you added the #define for scalepri, you used a
 blank instead of a tab-character between "#define" and "scalepri".
 One of the rules in style(9) is that #define's should be followed
 by a tab-character.  (I do not know why, but it is in the list of
 guidelines and I have no reason to *not* follow that that, so I
 follow it...)
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 08:53:38 -0400

 At 2:21 PM +0200 6/23/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  >
 >>  ...Okay.  On my present 5.x-system, when running from root, a
 >>  `ps -e' prints out exactly the same thing as `ps'.  This is
 >
 >mine is different !!! I suspect you have a patched kernel
 >somewhere ?
 
 I do not have any kernel patches.  Remember:  I usually do not
 do any work at the kernel level...  Maybe I have some setting
 set somewhere, but this issue does not interest me right now.
 
 >  > I have no intention of pursing this any further right now.
 >  > It is not critical to anything.  We can revisit the question
 >  > after we have run out of more useful updates to `ps'.
 >
 >it would be more appropriate to better document -e since the
 >behaviour has changed. something like :  [...]
 
 When I said "I have no intention...", I meant "I have NO intention".
 I did not mean "Please let us debate this some more right now, and
 thus delay all the other work we want to get done".
 
 And as I also said:  "we can revisit this later".
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 09:02:38 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >
 >below, there is some kernel fixes.
          [...]
 >src/lib/libkvm/kvm_proc.c :
 >	conditionnal fix
 >	strncpy -> strlcpy
 >
 >Index: src/lib/libkvm/kvm_proc.c
 >===================================================================
 >RCS file: /home/ncvs/src/lib/libkvm/kvm_proc.c,v
 >retrieving revision 1.76
 >diff -u -I$Id.*$ -I$.+BSD.*$ -r1.76 kvm_proc.c
 >--- src/lib/libkvm/kvm_proc.c	19 Jun 2004 14:08:10 -0000	1.76
 >+++ src/lib/libkvm/kvm_proc.c	22 Jun 2004 14:34:04 -0000
 >@@ -128,7 +128,7 @@
 >  				    TAILQ_FIRST(&proc.p_threads));
 >  				return (-1);
 >  			}
 >-			if (proc.p_flag & P_SA == 0) {
 >+			if ((proc.p_flag & P_SA) == 0) {
 >  				if (KREAD(kd,
 >  				    (u_long)TAILQ_FIRST(&proc.p_ksegrps),
 >  				    &mkg)) {
 >@@ -328,10 +328,8 @@
 >  				continue;
 >  			break;
 >  		}
 >-		if (proc.p_comm[0] != 0) {
 >-			strncpy(kp->ki_comm, proc.p_comm, MAXCOMLEN);
 >-			kp->ki_comm[MAXCOMLEN] = 0;
 >-		}
 >+		if (proc.p_comm[0] != 0)
 >+			strlcpy(kp->ki_comm, proc.p_comm, MAXCOMLEN);
 >  		(void)kvm_read(kd, (u_long)proc.p_sysent, (char *)&sysent,
 >  		    sizeof(sysent));
 >  		(void)kvm_read(kd, (u_long)sysent.sv_name, (char *)&svname,
 
 Hmm.  I had meant to get those in last week, as separate updates
 after doing my main update.  Obviously I forgot to.  I probably
 will try to get these two changes committed this week...
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 18:15:20 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >Hi,
 >
 >to help you in moving forward against my PR, here is some minor
 >fixes easy to handle.
 >
 >here is some little alignment fixes...
 
 I have committed most of these, with a few minor style fixes.
 
 >ps.c
 >   saveuser : defunct and [system proc] added, malloc check added.
 
 I did not add the check for "system proc".  On my system, the
 only process that seemed to effect was the "/sbin/init" process,
 and (personally) I would just as soon see "/sbin/init" instead
 of "[init]".  I did not spend too much time thinking about it,
 though.  It is probably reasonable to add that check.
 
 [I should mention that I am in a bit of a rush here, as the
 computer center where I work will have no power this weekend.
 Anything I do not get done before this Friday will probably
 have to wait until the end of *next* week.  And that weekend
 is a holiday weekend, so I may not get to it then, either...]
 
 >src/lib/libkvm/kvm_proc.c :
 >	conditionnal fix
 >	strncpy -> strlcpy
 
 I have also committed these.
 
 I am also hoping to get in the fix you described as:
       lib/libkvm/kvm_proc.c :
       ...
       ki_tdev was not filled the right way -- fixed.
       (dev2udev() taken from sys/kern/kern_conf.c)
 
 I am not sure that I will have the time to do that this week,
 but I do intend to get that committed "sometime soon".  I do
 want to get rid of the warning message from the current code,
 especially since that code is obviously doing the wrong thing!
 
 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >src/sys/kern/kern_proc.c
 >	default -> EINVAL
 
 I have no problem with this patch, but it is likely I will not
 get to it this week.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 19:43:45 -0400

 At 2:04 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >Hi, this patch is relative to the last fix sent a few
 >minutes ago :)
 >
 >struct varent -> VARENT
 >struct kinfo -> KINFO
 
 I do not understand why you want to do this.  What would be
 improved by it?  I believe that in general, the FreeBSD project
 does not like using typedef's to hide structs.  I know there are
 a few situations where a typedef does improve things, but I do
 not remember what those situations were.  In fact, one of the
 updates I have been meaning to try is to completely remove the
 VARENT and KINFO typedefs.  I am not sure that they serve any
 useful purpose.  Of course, I could be wrong about that!
 
 >-> queue(3)
 
 I am about to commit this part, with one change which is nothing
 more than my personal preference.  I tend to avoid very-generic
 variable names like "list", so I changed that to "next_ve".  I
 like more distinctive names, particularly since I will probably
 be adding other structs that use queue(8), and I like using
 unique "next element" names for each one.  I can not say there
 is anything wrong with using "list", it is just that I personally
 wanted to use something else.
 
 >diff -u /tmp/src/bin/ps/extern.h /usr/src/bin/ps/extern.h
 >--- /tmp/src/bin/ps/extern.h	Wed Jun 23 01:29:49 2004
 >+++ /usr/src/bin/ps/extern.h	Wed Jun 23 01:47:39 2004
 >  extern int sumrusage, termwidth, totwidth;
 >-extern VARENT *vhead;
 >+extern VARLIST varlist;
 
 
 >diff -u /tmp/src/bin/ps/ps.h /usr/src/bin/ps/ps.h
 >--- /tmp/src/bin/ps/ps.h	Sun Jun 20 23:25:10 2004
 >+++ /usr/src/bin/ps/ps.h	Wed Jun 23 01:45:02 2004
 >
 >+#include <sys/queue.h>
 >+
 
 >  /* Variables. */
 >+typedef STAILQ_HEAD(varlist, varent) VARLIST;
 >+
 
 There is no need to define this typedef for VARLIST, so I skipped
 it.  From reading the man page for queue(8), I am pretty sure that
 the standard way of doing this is to add:
 
 extern STAILQ_HEAD(velisthead, varent) varlist;
 
 to extern.h, and then use the line:
 
 struct velisthead varlist = STAILQ_HEAD_INITIALIZER(varlist);
 
 to initialize the real version of it in ps.c.  This seemed to work
 for me, at least.  If I am wrong, I am sure someone will correct
 me after I commit it!    :-)
 
 Thanks for doing this.  I think that I am going to use the queue(8)
 macros to fix my remaining problem with -O/-o in my format-rewrite,
 so this is something I wanted to see done.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Wed, 23 Jun 2004 21:09:29 -0400

 At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >Hi, here is the user lever tty related changes since you are
 >currently working on the kernel related ones (the netbsd way
 >I suppose ? :).
 
 I am skipping the part:    -t - and -t ? added
 because I am not working on that kernel change this week.
 We can do that at some later date.
 
 >ps.c
 >	_PATH_CONSOLE -> _PATH_CONSOLECTL, strdup not need here
 
 I was going to do use _PATH_CONSOLECTL, but that did not seem
 to work right on my machine:
 
 (67)  ps-rel5 -t co
    PID  TT  STAT      TIME COMMAND
    593 con- I+     0:00.00 /bin/sh /usr/local/sbin/thttpd_wrapper
 
 I may not have a complete understanding about what "console" is
 supposed to match, but I assure you that the above wrapper-script
 is not running on any console...  The above result may be due to
 some bug elsewhere, but it was enough that I will stick with
 _PATH_CONSOLE for now.  It may not be completely right to use
 _PATH_CONSOLE, but if we keep using it then no one can accuse us
 of introducing a bug.
 
 >	-t - and -t ? added.
 
 Skipped for now.
 
 >	-t ttyp0 added.
 
 The logic for this didn't work quite as I would like.  It does
 not work if someone does "-t console" -- and I believe that it
 should.  At least, it seems to on solaris and linux.  The
 present logic fails with:
       /dev/ttyconsole: No such file or directory
 
 As a user I find errors like that annoying.  I always think "Well,
 yes, *THAT* is an error -- but that is *NOT* what I asked for!".
 So I am going to adjust this logic so it comes closer to how I
 think it should work, and then I will commit that change.
 
 >pathnames.h
 >	new file
 >	how about to add _PATH_CONSOLECTL in <paths.h> instead ?
 
 I have dropped this due to the above testing.  But before I
 dropped it, I was going to just add the define in ps.c as:
 
 #ifndef _PATH_CONSOLECTL	/* This should really be in <paths.h> */
 #define	_PATH_CONSOLECTL	"/dev/consolectl"
 #endif
 
 My thinking was that there is no reason to create a new file just
 to hold one variable, when we REALLY want that variable to be in
 paths.h.  After someone does put it in paths.h, then we would have
 no reason for this file.
 
    - - - -
 After committing this update, I will probably go back to finish
 off my rewrite of the format-handling options.  Hopefully I can
 finish that tonight!
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 24 Jun 2004 02:09:46 -0400

 Well, I have something pretty close to what I intend to commit
 as the "new format-handling code".  Right now it is a 240-line
 patch, and my email client will sometimes reformat patches, so
 I have put the patch at:
 
 http://people.freebsd.org/~gad/ps-newfmt.diff
 
 I still want to rewrite some of the comments, and I also suspect
 there are a few combinations of options which do not work quite
 right.  I am pretty sure there are some cases with -O or -o that
 I want to handle a little differently, for instance.
 
 So, I may have a few more adjustments to do, but I do think this
 is pretty close to what I intend to commit.
 
 I hope you do not find it too frustrating that I am going in
 this direction instead of the direction of:
 
 	static char bsd_fmtstr[] = "\
 label:[0Z] user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:[02]! \
 ppid:[jl] pgid:j sid:j 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:[01]! \
 tt:[jls]([du]!)& start:u time:[01]! sl:v re:v pagein:v vsz:v([lu]!)& \
 rss:v([lu]!)& lim:v tsiz:v %cpu:v(u!)& %mem:v(u!)& command:[01]! \
 
 but I really think it would be a bad idea to go with something
 that complicated.  I suspect you spent a fair amount of time to
 get that to work right, but it is a nightmare when it comes to
 sharing code among thousands of developers.  If anyone wants to
 add a new format-group to the above format-string, they will
 first have to spend a fair amount of time just figuring out the
 logic behind that string.  That is work I would prefer to avoid,
 but it is not the thing which worries me the most.
 
 To my mind, there is a much bigger problem when it comes time to
 merge updates from multiple developers.  Any time any developer
 adds a format-group to that one string, the developer is almost
 certainly going to have to change every line in that string.  If
 you have two different developers who add different format-groups,
 then merging those two changes is much-too-much work.
 
 What I ended up with is based on work that I was already doing.
 When I started that, I had a much less ambitious goal in mind
 than you did.  I know that what I ended up with is still does not
 do everything that you wanted to do, but it does do more than I
 originally intended to do.  My hope is that this will be easy
 enough to add more features to (if we need them), and to add
 more format-groups.
 
 If I get really ambitious, I might commit this Thursday night.  My
 guess is that I will not really be able to commit it until Sunday
 evening (at the earliest).  I have a vague feeling that to get `-o'
 to always work the way I want it to, I will need to have two copies
 of the "fmtopts" variable.  One to hold all the format options
 specified before the first `'-o', and one to hold the options
 specified after that.  I may have to think about that some more.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 24 Jun 2004 03:06:20 -0400

 At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >ps.c
 >	_PATH_CONSOLE -> _PATH_CONSOLECTL
 
 I have another observation on this.  I finally got a successful
 buildworld/installworld on my sparc64 machine, and I tried the
 consolectl change on that.  It turns out there is *NO* device
 called consolectl on freebsd/sparc64.  So, we definitely can
 not do that change.
 
 In a different message, Garance wrote:
 >  It makes sense to add the case for PRI_ITHD, but why not
 >  include the value of "level"?   I.e., why did you go with:
 >	strncpy(str, "intr", sizeof(str));
 >  instead of:
 >	snprintf(str, sizeof(str), "intr:%u", level);
 >  ?
 
 Note that I do intend to commit this, once I know why "level"
 was skipped.  If the value of "level" is useless for PRI_ITHD,
 then I will commit the plain strncpy(*).  If there might be
 some use for it, I'll commit the snprintf version so that
 level is included.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Thu, 24 Jun 2004 14:11:58 -0400

 And now that I finally got my sparc64 system to build, I went
 back and compiled the `ps' with all your updates on it.  A few
 minor compile-time errors come up on sparc64, all in print.c.
 You changed:
 
 static void
 printval(void *bp, VAR *v)
 
 to
 
 static void
 printval(char *bp, VAR *v)
 
 and it turns out that this triggers a number of warnings in
 the select statement that follows:
 
     warning: cast increases required alignment of target type
 
 The only other issue is that printtime has a number of variables
 of type time_t, which are printed out with the format %02d.  On
 sparc64, time_t is 64-bits, so you have to use %02ld and then
 cast the variable to type (long).  You have to do the cast on
 the variable so that you avoid warnings on the *other* platforms,
 where time_t is an int instead of a long.
 
 No need for you to do anything about these.  I just thought I
 would mention them for future reference.  And these might be due
 to all the extra -Warning options that I compile with.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 18:07:54 -0400

 At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >
 >PS : could you remember me what is the time line for 6.x ?
 
 In a recent email to developers about something else, the
 following was mentioned:
 
      Although it has not been announced by re@, the general
      feeling is that the 5.3 code freeze is not more than a
      few months away.
 
 I have been working under the impression that the code freeze
 might start around July 17th.  It is still best for us to get
 things done as soon as possible, of course.  But it sounds
 like we will have more time than I had expected before we run
 into the code-freeze.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: cyrille.lefevre@laposte.net,
	freebsd gnats <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 18:38:46 -0400

 Earlier in this PR, you wrote:
 >  Garance wrote:
 >  >  I personally have no desire to end up with a version of `ps'
 >  >  which implements every option known to any other operating
 >  >  system under the sun.
 >
 >  I have not implemented all of them :) but the ones which, IMHO,
 >  are really interesting to have.  In the above example, since
 >  I have "ps -C", I'm using it really often instead of doing
 >  "ps -ef | grep [x]xxx" or such construction.
 
 For the specific example of -C, note that I think that the
 FreeBSD base system now has that covered by the `pgrep' command.
 That `pgrep' command does also exist on other operating systems.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 01:25:02 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 1:27 AM +0200 6/23/04, Cyrille Lefevre wrote:
 > >
 > >here is some little alignment fixes...
 > >
 > >started : right justify - if not ki_valid
 > 
 > I am not sure that we should change that.  And if we should change
 > it, then we should also change lstarted.  I am a bit tired right
 > now, so maybe we can revisit this when I am more awake.
 
 not seen !
 
 > >priorityr : handle PRI_ITHD ("intr")
 > 
 > It makes sense to add the case for PRI_ITHD, but why not include
 > the value of "level"?   I.e., why did you go with:
 > strncpy(str, "intr", sizeof(str));
 > instead of:
 > snprintf(str, sizeof(str), "intr:%u", level);
 > ?
 
 don't remember ?
 
 > >and some other simple fixes easy to handle...
 > 
 > I have committed some of these.  I will look at the rest when I
 > get back in later today.
 > 
 > Minor note:  When you added the #define for scalepri, you used a
 > blank instead of a tab-character between "#define" and "scalepri".
 > One of the rules in style(9) is that #define's should be followed
 > by a tab-character.  (I do not know why, but it is in the list of
 > guidelines and I have no reason to *not* follow that that, so I
 > follow it...)
 
 I'll take care of this...
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 01:42:41 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 2:04 AM +0200 6/23/04, Cyrille Lefevre wrote:
 > >Hi, this patch is relative to the last fix sent a few
 > >minutes ago :)
 > >
 > >struct varent -> VARENT
 > >struct kinfo -> KINFO
 > 
 > I do not understand why you want to do this.  What would be
 
 because most of the code uses them.
 
 > improved by it?  I believe that in general, the FreeBSD project
 
 it may help in line wrapping (not checked).
 
 > does not like using typedef's to hide structs.  I know there are
 
 no, the FreeBSD project does not line *_t typedefs to hide struct.
 
 # grep typedef /sys/sys/*h | wc
      443    2141   24815
 # grep 'typedef *struct' /sys/sys/*h | wc
      107     416    5191
 # grep 'typedef *struct.*_t' /sys/sys/*h | wc
       48     201    2685
 
 but that's the kernel part.
 
 > a few situations where a typedef does improve things, but I do
 > not remember what those situations were.  In fact, one of the
 > updates I have been meaning to try is to completely remove the
 > VARENT and KINFO typedefs.  I am not sure that they serve any
 > useful purpose.  Of course, I could be wrong about that!
 
 as a general rule, I try to keep historical things like this.
 
 [snip queue(2)]
 
 do whatever you want, I don't care.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 01:52:53 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 [snip]
 > >ps.c
 > > _PATH_CONSOLE -> _PATH_CONSOLECTL, strdup not need here
 > 
 > I was going to do use _PATH_CONSOLECTL, but that did not seem
 > to work right on my machine:
 > 
 > (67)  ps-rel5 -t co
 >    PID  TT  STAT      TIME COMMAND
 >    593 con- I+     0:00.00 /bin/sh /usr/local/sbin/thttpd_wrapper
 > 
 > I may not have a complete understanding about what "console" is
 
 try conscontrol(8), however having man console(4) would be better.
 
 [snip]
 > The logic for this didn't work quite as I would like.  It does
 > not work if someone does "-t console" -- and I believe that it
 > should.  At least, it seems to on solaris and linux.  The
 > present logic fails with:
 >       /dev/ttyconsole: No such file or directory
 
 console is supposed to be "co". however, replace :
 
 strncmp(elem, "co") == 0
 by
 strncmp(elem, "co") == 0 || strncmp(elem, "console") == 0
 
 > As a user I find errors like that annoying.  I always think "Well,
 > yes, *THAT* is an error -- but that is *NOT* what I asked for!".
 > So I am going to adjust this logic so it comes closer to how I
 > think it should work, and then I will commit that change.
 
 do whatever you want.
 
 > >pathnames.h
 > > new file
 > > how about to add _PATH_CONSOLECTL in <paths.h> instead ?
 > 
 > I have dropped this due to the above testing.  But before I
 > dropped it, I was going to just add the define in ps.c as:
 > 
 > #ifndef _PATH_CONSOLECTL /* This should really be in <paths.h> */
 > #define _PATH_CONSOLECTL "/dev/consolectl"
 > #endif
 > 
 > My thinking was that there is no reason to create a new file just
 > to hold one variable, when we REALLY want that variable to be in
 > paths.h.  After someone does put it in paths.h, then we would have
 > no reason for this file.
 
 under BSD, _PATH_* local definitions are always "pathnames.h".
 let's try find /usr/src -name pathnames.h | xargs grep -c _PATH_
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 01:55:24 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 > >ps.c
 > > _PATH_CONSOLE -> _PATH_CONSOLECTL
 > 
 > I have another observation on this.  I finally got a successful
 > buildworld/installworld on my sparc64 machine, and I tried the
 > consolectl change on that.  It turns out there is *NO* device
 > called consolectl on freebsd/sparc64.  So, we definitely can
 > not do that change.
 
 what is saying conscontrol ? under i386 :
 # conscontrol
 Configured: consolectl
  Available: ttyd0,consolectl
     Muting: off
 
 > In a different message, Garance wrote:
 > >  It makes sense to add the case for PRI_ITHD, but why not
 > >  include the value of "level"?   I.e., why did you go with:
 > > strncpy(str, "intr", sizeof(str));
 > >  instead of:
 > > snprintf(str, sizeof(str), "intr:%u", level);
 > >  ?
 > 
 > Note that I do intend to commit this, once I know why "level"
 > was skipped.  If the value of "level" is useless for PRI_ITHD,
 > then I will commit the plain strncpy(*).  If there might be
 > some use for it, I'll commit the snprintf version so that
 > level is included.
 
 I think it was not intentionaly skipped, but forgotten when
 PRI_ITHD was added to FreeBSD.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 01:58:53 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > And now that I finally got my sparc64 system to build, I went
 > back and compiled the `ps' with all your updates on it.  A few
 > minor compile-time errors come up on sparc64, all in print.c.
 > You changed:
 > 
 > static void
 > printval(void *bp, VAR *v)
 > 
 > to
 > 
 > static void
 > printval(char *bp, VAR *v)
 > 
 > and it turns out that this triggers a number of warnings in
 > the select statement that follows:
 > 
 >     warning: cast increases required alignment of target type
 
 it looks I made a mistake here. it was not intentional.
 
 > The only other issue is that printtime has a number of variables
 > of type time_t, which are printed out with the format %02d.  On
 > sparc64, time_t is 64-bits, so you have to use %02ld and then
 > cast the variable to type (long).  You have to do the cast on
 > the variable so that you avoid warnings on the *other* platforms,
 > where time_t is an int instead of a long.
 
 thanks.
 
 > No need for you to do anything about these.  I just thought I
 > would mention them for future reference.  And these might be due
 > to all the extra -Warning options that I compile with.
 
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 02:34:44 +0200

 Hi,
 
 you know what ? I'm desesperated. you never said what you intend to do.
 you ask me for one thing and you work and commit something else. you never
 showup the code you are supposed to have already written. so, I've really
 have some doubt about its existence.
 
 ok, you have the commit bit I don't have. also ok that I never asked for it.
 so, I have to rely on someone which have one. but it's the first time I see
 someone which rewrote almost all of what I've done in many ways.
 
 so, I'm tired. I'm tired to debate on things which don't follow what other
 systems does. I'm tired to see things rewritten in a way I dislike. I've
 worked hard and for a long time on this and I've tested all the features
 I've added.
 
 I've also tried to cleanup the code in many way and I find that the actual
 code is getting more and more dirty. ok, my code isn't probably perfect and
 it probably contains some minor bugs or style(9) bugs, as almost all the
 codes here and there, but not so important regarding the work done.
 
 in other words, it's enough. I give up on this project. go the way you want,
 I don't care. break ps the way you want, I don't care. make ps as dirty as
 possible, I don't care. continue to rewrite the code I've written the way
 you want, I don't care.
 
 I've one working very well for my needs and will provide it as a port w/
 the feature I want and the way I want, that's all.
 
 I'm just asking you two things : close this PR and never handle one of my PRs.
 in regards, I'll take care of not submitting anything relative to you work.
 
 thank you and good luck.
 
 PS : maybe I'm looking paranoid, but I'm not, for sure.
 
 PS2 : just seens the "newfmt" code... and you say that my code is not
 understandable. I far prefer mine to your. I really dislike mixed case
 and _. take a look at the code around (say FreeBSD) and you never see
 that.
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
 

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 21:19:01 -0400

 At 1:25 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  > >priorityr : handle PRI_ITHD ("intr")
 >>
 >>  It makes sense to add the case for PRI_ITHD, but why not include
 >>  the value of "level"?   I.e., why did you go with:
 >>      strncpy(str, "intr", sizeof(str));
 >>  instead of:
 >>      snprintf(str, sizeof(str), "intr:%u", level);
 >>  ?
 >
 >don't remember ?
 
 I think I will commit a version which shows the level, and then
 let someone else tell me if that is pointless to do.  The value
 did seem to be different for different processes, and my GUESS
 is that there might be some cases where it would be useful to
 see what the different values are.
 
 >  > Minor note:  When you added the #define for scalepri, you used a
 >>  blank instead of a tab-character between "#define" and "scalepri".
 >>  One of the rules in style(9) is that #define's should be followed
 >>  by a tab-character.  (I do not know why, but it is in the list of
 >>  guidelines and I have no reason to *not* follow that that, so I
 >>  follow it...)
 >
 >I'll take care of this...
 
 Hmm, I think I have already committed a version which has this
 fixed.  It was a minor detail, so there was no sense delaying
 the commit when I could just fix it and commit it.  I mentioned
 it only so you're aware of it when you are writing updates.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 21:32:18 -0400

 At 1:52 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >
 >>  >pathnames.h
 >>  > new file
 >>  > how about to add _PATH_CONSOLECTL in <paths.h> instead ?
 >>
 >>  I have dropped this due to the above testing.  But before I
 >>  dropped it, I was going to just add the define in ps.c as:
 >>
 >  > #ifndef _PATH_CONSOLECTL /* This should really be in <paths.h> */
 >>  #define _PATH_CONSOLECTL "/dev/consolectl"
 >>  #endif
 >>
 >>  My thinking was that there is no reason to create a new file just
 >>  to hold one variable, when we REALLY want that variable to be in
 >>  paths.h.  After someone does put it in paths.h, then we would have
 >>  no reason for this file.
 >
 >under BSD, _PATH_* local definitions are always "pathnames.h".
 >let's try find /usr/src -name pathnames.h | xargs grep -c _PATH_
 
 This is true.  And if we really intended to keep _PATH_CONSOLECTL
 as part of `ps', then your update makes sense.  Or if we had some
 other values to put into pathname.h, then it would also be quite
 right to add that definition to pathnames.h.
 
 What I was thinking was that in THIS case, we really want this
 variable defined in paths.h.  I was thinking that I could get that
 change committed to paths.h sometime in the next week or two.  As
 soon as this variable was in paths.h, would be no reason for `ps'
 to have a pathnames.h.  So, I just wanted to avoid creating a new
 file in the CVS repository, when I had every intention of
 destroying that same file in less than two weeks.
 
 Or do we have some other variables that we should have in a
 pathnames.h?  I did not notice any other _PATH variables added
 by your update.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 21:37:54 -0400

 At 1:52 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >[snip]
 >>  The logic for this didn't work quite as I would like.  It does
 >>  not work if someone does "-t console" -- and I believe that it
 >>  should.  At least, it seems to on solaris and linux.  The
 >>  present logic fails with:
 >>        /dev/ttyconsole: No such file or directory
 >
 >console is supposed to be "co". however, replace :
 >
 >strncmp(elem, "co") == 0
 >by
 >strncmp(elem, "co") == 0 || strncmp(elem, "console") == 0
 
 Well, I could have done that to fix the specific case of console,
 but that was not what I was thinking of when I wrote that part
 of my message.  What I meant was that I find it annoying when I
 type in one thing, and the system reports an error message after
 CHANGING what I had typed in.
 
 However...  It seems my "better" fix for this is still not quite
 right, so I have to look at that again.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Fri, 25 Jun 2004 21:50:47 -0400

 At 1:55 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >>  At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 >>  > ps.c
 >>  >     _PATH_CONSOLE -> _PATH_CONSOLECTL
 >>
 >>  I have another observation on this.  I finally got a successful
 >>  buildworld/installworld on my sparc64 machine, and I tried the
 >>  consolectl change on that.  It turns out there is *NO* device
 >>  called consolectl on freebsd/sparc64.  So, we definitely can
 >>  not do that change.
 >
 >what is saying conscontrol ? under i386 :
 ># conscontrol
 >Configured: consolectl
 >  Available: ttyd0,consolectl
 >     Muting: off
 
 On alpha, it says:
 
 (51)  conscontrol
 Configured: ttyd0
   Available: promcons,ttyd0
      Muting: off
 
 (and it looks like /dev/consolectl *DOES* seem to exist on alpha)
 
 On sparc64, it says:
 
 (11)  conscontrol
 Configured: ofwcons
   Available: ofwcons
      Muting: off
 
 (which probably stands for open-firmware console).  I tried a
 `ps-rel5 -t ofwcons', and that does pick up a session that I have
 going on the console:
 
 (21)  ps-rel5 -t ofwcons -O user
    PID USER  TT  STAT      TIME COMMAND
   1183 root scr  Ss     0:00.32 login [pam] (login)
   9817 gad  scr  S+     0:00.29 -bash (bash)
 
 and `ps -t console' does not catch that session.  So, I think it
 would be nice figure out what is going on there.  We can't blindly
 use /dev/consolectl, but we might want to make some kind of change
 after we figure out how these pieces all fit together.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 00:49:43 -0400

 At 2:33 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  > After I read your description, I thought "gee, I can do that
 >  > with only a bit more shuffling around".  However, once I got
 >  > to the final result I really did not like it.  I kept
 >  > thinking:
 >  >      But *why* should `-uv' be the same as `-vu'?
 >
 >for at least two reasons :
 >- because all other system go this way
 
 Hmm.  They don't all go this way, but it does look like more
 of them go this way than I had thought in my initial testing.
 
 >- because SUSv3 say :
 >
 >[XSI]
 >    On XSI-conformant systems, the output format shall be as
 >    follows. The column headings and descriptions of the
 >    columns in a ps listing are given below.  The precise
 >    meanings of these fields are implementation-defined. The
 >    letters 'f' and 'l' (below) indicate the option (full or
 >    long) that shall cause the corresponding heading to appear;
 >    all means that the heading always appears. Note that these
 >    two options determine only what information is provided for
 >    a process; they do not determine which processes are listed."
 
 Indeed.  I read that too.  The thing is, that only tells us what
 order `-f' and `-l' have to be in -- and we (FreeBSD) do not
 even have the `-f' format option.  And what we have for the `-l'
 format is significantly different than the standard `-l', and I
 do not intend to change what a plain `-l' does (not in this
 update, at least).  Please note that this update is only meant
 to clean up the formats in a "BSD ps".  Right now our `ps' is
 nowhere near being SUSv3, and this update does not claim to
 fix that.
 
 Notice that SUSv3 says nothing about what `-j', `-v' or `-u'
 should do -- because SUSv3 does not include those three options.
 And if I even try to do multiple BSD-ish options on AIX, I see:
 
 (8)  ps vl
 ps: Specify only one of s,l,v and u
 
 So, when I read that section in SUSv3, I was not sure on how
 much that could really apply to `ps' on BSD.
 
 Also, when I read it I noticed that text only says what columns
 must be present.  It does not state that the columns must be in
 any specific order.  It also does not say that the given order
 must be the order used when combining options.  I agree that
 it prefers that order, but it does not actually state that
 the columns *must* be in that order.
 
 Also, that "XSI" indicates this section is describing an "X/Open
 System Interfaces Extension".  I don't think we are as concerned
 with XSI extensions as we are with basic features of SUSv3.
 
 ...But let me say again, this update is NOT intended to help
 us follow SUSv3.  All this is meant to do is clean up some
 format-handling issues.  As I have said before, this is work I
 was doing before you sent in your PR.  It really has nothing
 much to do with the work you have done.
 
 >  > I ran into this debate (with myself) when trying to decide
 >  > what the "ideal order" should be for any particular
 >  > combination.  While I could come up with some order that *I*
 >  > liked, there was no way I  could say why `ps' *must* use
 >  > that order I liked.
 >
 >as I can see, the order *YOU* liked, not the order what other
 >systems does? continue like this and you'll get a Linux'ed
 >FreeBSD!
 
 I think you misunderstood my point here.  I also did *not*
 like that I was picking "what I liked".  When it came to other
 operating systems, I could only check what they did for -f and
 -l (and we don't have -f).  I do intend to follow their lead
 for -l, but that does not tell me how I should *combine* options.
 So when it came to combining the options that they don't support,
 the only thing I could do is "what I liked".
 
 When you combined format-groups of -v, -u, -j, along with all
 the others, what "standard" were you following to pick the order
 of the columns?  I am honestly curious here.  If there is some
 official standard which covers those options, then I agree it
 would make sense to follow that standard.
 
 >  > The strategy when combining multiple format-groups is basically:
 >  >     a) combine everything that is before the "pid" columns.
 >>      b) if Z is specified, add the "label" column
 >>      c) add the "pid" column
 >      c2)     O-options...
 >  >     d) combine everything that is after the "pid" columns, ...
 >>      e) except that "comm" or "command" is always moved to
 >>         the last column.
 >
 >as I can see, you have taken you inspiration from the Linux
 >ps, no?
 
 Actually, no.  Not when it came to combining format-groups.  I
 did check what any specific format-group looked like, but not
 the combinations.  Given that we have several format-groups,
 what I wanted was some simple algorithm that could be applied
 to these groups, plus any more groups that we would want to add.
 This is one algorithm which seems to work well, and which is
 certainly much better than what our `ps' is currently doing.
 
 [but I find that I am still changing my mind on what the exact
 set of steps should be]
 
 In any case, if any particular combination does have to have a
 specific order (no matter what order the user specified the
 options), then I can switch this around to do that instead.
 
 >please, don't mixup -o/-O w/ any other option. remember you :
 >
 >"When the -o option is not specified, the standard output
 >format is unspecified.
 >
 >etc."
 
 Yes, the *standard* output format is unspecified.  But if the
 user has specifically requested some additional output formats,
 I did not think we should ignore them.
 
 And when it comes to -O, we *have* to mix it up with other
 formats.  The way we do it right now seems pretty bogus to me.
 And since `-O' is a BSD-only option, we do have more leeway to
 decide how we want it to work.
 
 I will admit that I am still not quite happy with how my NEWFMT
 handles -O and -o, so I am still trying to decide what I want to
 do there.  It is more and more likely that I will not get this
 committed before July, but I thought you would want to comment
 on the direction I was going before I committed this.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sat, 26 Jun 2004 02:27:57 -0400

 At 2:34 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >Hi,
 >
 >you know what ? I'm desesperated.
 
 Hrm.  I am not sure what word you wanted there.  "depressed"?
 Well, whatever it is, I suspect you did not mean "happy".
 
 Hmm.  Well, the office I am in will lose all electrical power
 in about two hours (and remain out for at least 18 hours), so
 I will just type up my thoughts and call it a day.
 
 >you never said what you intend to do.  You ask me for one thing
 >and you work and commit something else.
 
 I tried to explain this to you in my series of three messages,
 which I sent back on June 13th.  Actually I have not expected
 you to do *anything* just yet.
 
 Back on the 12th and 13th, I spent most of my weekend going
 through your large update, to see how usable it was.  After I
 saw how many different issues there were, my decision was that
 it would be easier to simply finish off the updates I had been
 working on.  And that *is* what I told you on that date.
 
 Since that date, I have made 15 actual commits to `ps', and a
 few kernel-related updates.  All of the kernel-related updates
 have been based on your patch, except for the fix from Bruce
 for calcru().  Nine of the changes to `ps' have been directly
 from your changes, and the change for queue macros was about
 half yours and half reworked by me.  Two of the remaining
 changes were fixes that Bruce Evans sent me.
 
 Some of those changes were modified by me as I committed them,
 but that was mostly to fix STYLE ERRORS in the version you had.
 The only change which was really full of my personal opinion
 was the half of the queue(8) change that I reworked, and the
 commit message for that does say "part by Cyrille Lefevre,
 part of it done by me".
 
 During that time, I also spent time testing updates from your
 patch which DID NOT WORK.  They need more investigation, and
 to me it makes sense to commit the stuff that clearly does
 work before spending any time on the remaining parts.  I do
 expect those parts can be fixed once we have some time, but
 why not commit some of the "easy stuff" first?
 
 >you never said what you intend to do.
 
 Back on the third message of June 13th, I explicitly said:
 
    "In general though, I am going to return to the changes
     that I had started on back in March, polish them off,
     and commit them.  And then we can figure out what
     should be done as the next set of updates."
 
 I also said:
 
     "... But right now I do not want you to spend even more
     effort to try and address every single issue that I have
     just described, when I know that I will be committing more
     of my own updates before I get back to these changes.
     However, I do like parts of this patch, and I do expect
     to get back to you after working on my pending updates."
 
  From my point of view, those passages should make it quite
 clear what I intended to do.  I do not know how I could have
 said it any clearer.  It may not have been what you wanted
 to hear, but I did state *exactly* what I intended to do.
 
 But even after I said that, most of my time for the past two
 weeks has been spent working on your updates, not on mine.
 I expect your own `ps' work will be easier due to the kern-
 related commits, if nothing else.  I thought you would be
 happy to see that those things were committed.
 
 >You ask me for one thing
 >and you work and commit something else. you never showup the
 >code you are supposed to have already written. so, I've really
 >have some doubt about its existence.
 
 I do not post my changes before *I* am happy with them. I do
 not care about "your doubt".  I have no desire to publicly
 debate some work-in-progress that I have, when I am still
 debating some parts of it with myself.  If I did, I am sure
 you would want to comment on them.  By the time you wrote up
 what you thought about it, I would have already changed it to
 something else.  I am sure you would find that frustrating.
 Or at least I would find that frustrating, if I were you.  I
 see no point in me posting any update when I know that I am
 still making changes to it.
 
 At this point, I only have two major updates left.  The NEWFMT
 one, and a separate one which attempts to add more SUSv3-ish
 support to `ps'.  I *DID* post the NEWFMT one to this PR so
 you could comment before I committed it -- and I am already
 thinking that I made a mistake by posting it too early.  I
 probably should not have posted it when I knew that I was
 still was not happy with how it handles -O/-o.
 
 >I'm just asking you two things : close this PR and never handle
 >one of my PRs.  In regards, I'll take care of not submitting
 >anything relative to you work.
 
 I will leave it open for the time being, but I do not expect
 to write any more replies for awhile.  I do still hope to pull
 in more of the changes that you posted in here.  I also expect
 to work on it at a slower pace.
 
 >PS2 : just seens the "newfmt" code... and you say that my code
 >is not understandable. I far prefer mine to yours.
 
 Hmm.  Actually I do think my code came out looking reasonably
 nice and easy to understand.
 
 >I really dislike mixed case and _. take a look at the code
 >around (say FreeBSD) and you never see that.
 
 Ah, that part is true.  Other than the variable names, though,
 I think the code itself is very easy to follow.  I should
 probably change some of those names.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: Garance A Drosihn <drosih@rpi.edu>
To: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>,
	"freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Sun, 27 Jun 2004 19:45:28 -0400

 At 1:42 AM +0200 6/26/04, Cyrille Lefevre wrote:
 >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 >  > ... I believe that in general, the FreeBSD project
 >  > does not like using typedef's to hide structs.
 >
 >no, the FreeBSD project does not line *_t typedefs to hide struct.
 >
 ># grep typedef /sys/sys/*h | wc
 >      443    2141   24815
 ># grep 'typedef *struct' /sys/sys/*h | wc
 >      107     416    5191
 ># grep 'typedef *struct.*_t' /sys/sys/*h | wc
 >       48     201    2685
 
 My position is based on this passage from style(9):
 
      Avoid using typedefs for structure types.  Typedefs are problematic
      because they do not properly hide their underlying type; for example
      you need to know if the typedef is the structure itself or a pointer
      to the structure.  In addition they must be declared exactly once,
      whereas an incomplete structure type can be mentioned as many times
      as necessary.  Typedefs are difficult to use in stand-alone header
      files: the header that defines the typedef must be included before
      the header that uses it, or by the header that uses it (which causes
      namespace pollution), or there must be a back-door mechanism for
      obtaining the typedef.
 
 I am not making up my own arbitrary rules to annoy you.  I am
 just doing my best to follow these guidelines that all FreeBSD
 committers are asked to follow when they make commits to the
 base system.  I admit that my own code does not always match
 style(9), but I do *try* to follow it as much as I can.
 
 -- 
 Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu

From: "Cyrille Lefevre" <cyrille.lefevre@laposte.net>
To: "freebsd gnats" <freebsd-gnats-submit@FreeBSD.org>,
	"Garance A Drosihn" <drosih@rpi.edu>
Cc:  
Subject: Re: bin/65803: bin/ps enhancements (posix syntax, and more)
Date: Mon, 28 Jun 2004 12:56:25 +0200

 "Garance A Drosihn" <drosih@rpi.edu> wrote:
 > At 1:55 AM +0200 6/26/04, Cyrille Lefevre wrote:
 > >"Garance A Drosihn" <drosih@rpi.edu> wrote:
 > >>  At 3:22 AM +0200 6/23/04, Cyrille Lefevre wrote:
 > >>  > ps.c
 > >>  >     _PATH_CONSOLE -> _PATH_CONSOLECTL
 > >>
 > >>  I have another observation on this.  I finally got a successful
 > >>  buildworld/installworld on my sparc64 machine, and I tried the
 > >>  consolectl change on that.  It turns out there is *NO* device
 > >>  called consolectl on freebsd/sparc64.  So, we definitely can
 > >>  not do that change.
 > >
 > >what is saying conscontrol ? under i386 :
 > ># conscontrol
 > >Configured: consolectl
 > >  Available: ttyd0,consolectl
 > >     Muting: off
 > 
 > On alpha, it says:
 > 
 > (51)  conscontrol
 > Configured: ttyd0
 >   Available: promcons,ttyd0
 >      Muting: off
 > 
 > (and it looks like /dev/consolectl *DOES* seem to exist on alpha)
 > 
 > On sparc64, it says:
 > 
 > (11)  conscontrol
 > Configured: ofwcons
 >   Available: ofwcons
 >      Muting: off
 > 
 > (which probably stands for open-firmware console).  I tried a
 > `ps-rel5 -t ofwcons', and that does pick up a session that I have
 > going on the console:
 > 
 > (21)  ps-rel5 -t ofwcons -O user
 >    PID USER  TT  STAT      TIME COMMAND
 >   1183 root scr  Ss     0:00.32 login [pam] (login)
 >   9817 gad  scr  S+     0:00.29 -bash (bash)
 > 
 > and `ps -t console' does not catch that session.  So, I think it
 > would be nice figure out what is going on there.  We can't blindly
 > use /dev/consolectl, but we might want to make some kind of change
 > after we figure out how these pieces all fit together.
 
 since you help me here, here is the code I use to check for terminals.
 it does not match -current, but the logic is there.
 
 static void *
 addtty(LIST *list, char *arg)
 {
         static struct stat sb;
         const char *ttypath, *devpath;
         char pathbuf[SPECNAMELEN + 1];
         int try_again = 1;
 
         /*
          * allowed terminal name must be smaller than SPECNAMELEN and
          * maybe one of :
          * co -> /dev/consolectl (not /dev/console)
          * XX -> /dev/XX or /dev/ttyXX
          * ttyXX -> /dev/ttyXX
          * /dev/ttyXX -> /dev/ttyXX
          * ? or -
          */
         switch (*arg) {
         case '?':       /* may be ??, etc. */
         case '-':
                 ttypath = NULL;
                 sb.st_rdev = *arg == '?' ? KERN_PROC_TTY_NODEV :
                     KERN_PROC_TTY_REVOKE;
                 break;
         case '/':
                 ttypath = arg;
                 try_again = 0;
                 break;
         case 'c':
                 if (strcmp(arg, "co") == 0 || strcmp(arg, "console") == 0) {
                         static char *ctty = NULL;
 
                         if (!ctty)
                                 ctty = find_console();
                         arg = ctty;
                         try_again = 0;
                 }
                 /* FALLTHROUGH */
         default:
                 ttypath = pathbuf;
 retry:
                 devpath = !try_again || strncmp(arg, "tty", 3) == 0 ?
                     _PATH_DEV : _PATH_TTY;
                 if ((strlen(arg) + strlen(devpath)) > SPECNAMELEN) {
                         warnx("%s: %s name too long", arg, list->msg);
                         fatal = 1;
                         return(NULL);
                 }
                 snprintf(pathbuf, sizeof(pathbuf), "%s%s", devpath, arg);
         }
         if (ttypath) {
                 if (stat(ttypath, &sb) == -1) {
                         if (try_again) {
                                 try_again = 0;
                                 goto retry;
                         }
                         warn("%s", ttypath);
                         fatal = 1;
                         return (NULL);
                 }
                 if (!S_ISCHR(sb.st_mode)) {
                         warn("%s: not a %s", ttypath, list->msg);
                         fatal = 1;
                         return(NULL);
                 }
         }
         return((void *)&sb.st_rdev);
 }
 
 /*
  * based on src/sbin/conscontrol/conscontrol.c 1.4
  */
 static char *
 find_console()
 {
         static const char *ctty_oid = "kern.console";
         size_t len;
         char *buf, *p;
 
         if (sysctlbyname(ctty_oid, NULL, &len, NULL, 0) == -1)
                 err(1, "%s estimate failed", ctty_oid);
         if ((buf = malloc(len)) == NULL)
                 errx(1, "%s malloc failed", ctty_oid);
         if (sysctlbyname(ctty_oid, buf, &len, NULL, 0) == -1)
                 err(1, "%s retrieval failed", ctty_oid);
         if ((p = strchr(buf, '/')) == NULL)
                 errx(1, "%s format not understood", ctty_oid);
         *p = '\0';
         if (*--p == ',')
                 *p = '\0';                      /* remove trailing ',' */
         return(buf);
 }
 
 
 Cyrille Lefevre.
 -- 
 home: mailto:cyrille.lefevre@laposte.net
>Unformatted:
