Date: Wed, 12 Jun 2002 03:13:30 +0200 From: Cyrille Lefevre <cyrille.lefevre@laposte.net> To: Juli Mallett <jmallett@FreeBSD.org> Cc: standards@FreeBSD.org Subject: Re: cvs commit: www/en/projects/c99 index.sgml Message-ID: <20020612011330.GA45415@gits.dyndns.org> In-Reply-To: <20020610202431.A30207@FreeBSD.ORG> References: <200206070217.g572HH584853@freefall.freebsd.org> <20020606194448.A23497@FreeBSD.ORG> <20020611030857.GB14401@gits.dyndns.org> <20020610202431.A30207@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 10, 2002 at 08:24:33PM -0700, Juli Mallett wrote:
> * Cyrille Lefevre <cyrille.lefevre@laposte.net> escriurÃ?res
[snip]
> task. There's a lot of different approaches that could be taken with dealing
> with ps(1), as it's one of those unpleasent situations where compromises, etc.,
some of the possible approaches are :
1) a la HPUX : use an environment variable (UNIX95) to deal w/ some standard.
2) a la Tru64 or AIX : BSD options aren't dash (-) prefixed.
3) a la SunOS : use different commands located in different paths.
4) yet another approach : use a different command name to deal w/ some standard.
5) try to merge BSD and System V options. in my opinion, this is really
possible except by breaking the former or the later standard since
similar options may behave differently such as -u (different meaning)
or -j (different output).
6) use a command line option to switch from one or the other behaviour.
the current implementation complies w/ 1), 2), 4) and 6).
> may be made, and it's important those things aren't in the hands of one single
> person, and I'm an agreeable person, and as such happy to coordinate to come
^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure you are :)
> up with the best conformant ps(1) we can have! :)
>
> > ps(1) I'm working on.
>
> Thanks.
you're wecome.
> > PS : I've tryed to subscribe to this list twince w/o success, any ideas ?
>
> majordomo can be difficult, a message to majordomo@FreeBSD.org with contents
> of "subscribe freebsd-standaards" or "subscribe standards" should work.
found the problem, I've tryed to subscribe w/ different from (the
one in the header) and subscribe (the one in the body) addresses
while they MUST be the sames.
[snip]
> > differences between BSD and SUSV3 ps(1). also, the manual would
> > have to be updated to reflect the reallity (any volunteer ? :).
>
> The manual page may prove to be one of the least pleasent tasks, as while
> SUS/POSIX has taken from BSD manpages before, we are not allowed to use
> their text.
don't know that !
[snip]
> > new compilation flags :
> >
> > COMPAT_BSD44
> > be strictly compatible w/ BSD44 ps, else :
> > * -p, -t and -U respectively accept a list of pids, ttys
> > or users instead of a single one.
> > * -t accept ttyXX in addition to /dev/ttyXX and XX.
> > * -U also accept uids in addition of user names.
> > * output is formated more intelligently when combining
> > options such as -j, -l, -u and -v. format strings are
> > combined instead of being concatenated.
> > * -o keyword=header now works for aliased keywords, also,
> > -o keyword= don't print an empty line anymore, if any.
> >
> > COMPAT_SUSV2
> > be compatible w/ SUSV2 ps if the SUSV2 environment variable
> > has a non-zero value or if called as ps5. this may be
> > overriden using the new -B (BSD) or -V (SUSV2) options.
> > SUSV2 is automagically disabled when using pre BSD44 options.
> > SUSV2 options are, in fact, almost the SYSV ones.
> >
> > here is the usage string :
> >
> > usage: ps [-AaBdefjl] [-C cmdlist] [-g pgrplist] [-G grouplist] [-o fmt]
> > [-p pidlist] [-t ttylist] [-u userlist] [-U userlist]
> > [-m core] [-n system] [-w swap]
> >
> > here are the new -o keywords w/ their BSD44 counterpart,
> > if any, in parentheses :
> >
> > addr (paddr), args (command), c, comm (command),
> > etime, group, l (state), rgroup and stime.
> > and the ones which are affected when SUSV2 is enable :
> >
> > pri and time.
forgot `sid' which isn't implemented yet.
> Why can't these be there by default?
there are, but their output is different from BSD and SystemV.
let's try :
# ps5 -VO pri,time | head -2
PID PRI TIME TT COMMAND
1326 32 00:00:00 p0- sh
# ps5 -BO pri,time | head -2
PID PRI TIME TT STAT COMMAND
1326 10 0:00.53 p0- I /bin/sh /etc/rc.local.netstat
PS : just added -O to SystemV options as SUSV3 authorize it on BSD
implementations of ps(1).
> > NO_SWAP
> > disable -W option since kvm(3) doesn't read swap for almost
> > 10 years.
> >
> > also, single-linked tail queues have been converted to queue(3).
>
> This is a mixed thing. Some people will rightly say that conversion of a
> simplistic paradigm of code to the queue(3) constructs can be obfuscatory,
> and certainly macros which evolved after 4.3BSD sometimes differ in their
> meaning. TAILQ_FOREACH{,_REVERSE} on OSX bit me particularly hard.
I do that last year after reading a thread asking to do so. ask O'brien
(probably) for details :)
> > Index: Makefile
> > ===================================================================
> > RCS file: /home/ncvs/src/bin/ps/Makefile,v
> > retrieving revision 1.13
> > diff -u -r1.13 Makefile
> > --- Makefile 17 Nov 1999 13:37:30 -0000 1.13
> > +++ Makefile 11 Jun 2002 03:02:38 -0000
> > @@ -9,7 +9,12 @@
> > # keep ps from being an unnecessary load
> > # on large systems.
> > #
> > -CFLAGS+=-I${.CURDIR}/../../sys -DLAZY_PS
> > +CFLAGS= -g
> > +CFLAGS+= -I${.CURDIR}/../../sys
> > +CFLAGS+= -DBACKWARD_COMPATIBILITY
> > +CFLAGS+= -DLAZY_PS
> > +# CFLAGS+= -DCOMPAT_BSD44
> > +CFLAGS+= -DCOMPAT_SUSV2
> > DPADD= ${LIBM} ${LIBKVM}
> > LDADD= -lm -lkvm
> > #BINGRP= kmem
>
> There should be a make(1) tunable to handle the SUS compatability so that
since BSD and SystemV ps are really different in some way, it would be
better to consider a runtime (evan sysctl, why not ?) tunable to
deal w/ SUS compatability than a static make(1) tunable.
considering a runtime tunable, the current DEFINES in use are more
there to mark the code change than to make a choice between behaviours.
w/ COMPAT_BSD44 undefined, -p and such options allow a pidlist and
combining -j and such options is done more intelligently than before.
w/ COMPAT_SUSV2 define, you may switch from BSD and SUS behaviour.
that's all. in other words, I'm really against breaking whatever
compatibility using some compromise.
> a system being tested for standards conformance could have a flag such
> as:
> POSIX_CONFORM= NOBSD
>
> To disable BSD things that conflict with POSIX and use POSIX instead, or:
> POSIX_CONFORM= NOCONFLICT
>
> To use POSIX things where there's no conflict with BSD, but which are not
> meaningful in BSD (things related to sysv runtimes come to mind).
IMHO, nothing is not meaningfull in BSD nor nothing is meaningfull in SystemV.
they just do the same work differently and should continue this way to not
broke anything.
> The rest of it looks straightforward in places, but some of the changes look
> a bit big and I'd like to see what later comes up wrt susv3 and patches to the
> current version of ps(1).
well, I should have run diff -w to reduce the diffs but not so much
(64 lines less, that's all).
for instance, I've just reprinted all ps(1) manual pages from
BSD, SUSV3, HP-UX 11, Tru64 5, Solaris 9 and AIX 5 and will try
make a big table of compatibilities against each other with a
priority to BSD and SUSV3 of course, then, I could make a good
comparison w/ the current code and finish the work :)
Cyrille.
--
Cyrille Lefevre mailto:cyrille.lefevre@laposte.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020612011330.GA45415>