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=C3?res
[snip]
> task. There's a lot of different approaches that could be taken with dea=
ling
> 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 standar=
d.
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 stan=
dard.
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 s=
ingle
> person, and I'm an agreeable person, and as such happy to coordinate to c=
ome
^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure you are :)
> up with the best conformant ps(1) we can have! :)
>=20
> > ps(1) I'm working on.
>=20
> Thanks.
you're wecome.
> > PS : I've tryed to subscribe to this list twince w/o success, any ideas=
?
>=20
> majordomo can be difficult, a message to majordomo@FreeBSD.org with conte=
nts
> 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 ? :).
>=20
> 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 :
> >=20
> > 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=3Dheader now works for aliased keywords, also,
> > -o keyword=3D don't print an empty line anymore, if any.
> >=20
> > 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.
> >=20
> > here is the usage string :
> >=20
> > 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]
> >=20
> > here are the new -o keywords w/ their BSD44 counterpart,
> > if any, in parentheses :
> >=20
> > addr (paddr), args (command), c, comm (command),
> > etime, group, l (state), rgroup and stime.
> > and the ones which are affected when SUSV2 is enable :
> >=20
> > 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.
> >=20
> > also, single-linked tail queues have been converted to queue(3).
>=20
> 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
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > 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+=3D-I${.CURDIR}/../../sys -DLAZY_PS
> > +CFLAGS=3D -g
> > +CFLAGS+=3D -I${.CURDIR}/../../sys
> > +CFLAGS+=3D -DBACKWARD_COMPATIBILITY
> > +CFLAGS+=3D -DLAZY_PS
> > +# CFLAGS+=3D -DCOMPAT_BSD44
> > +CFLAGS+=3D -DCOMPAT_SUSV2
> > DPADD=3D ${LIBM} ${LIBKVM}
> > LDADD=3D -lm -lkvm
> > #BINGRP=3D kmem
>=20
> 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=3D NOBSD
>=20
> To disable BSD things that conflict with POSIX and use POSIX instead, or:
> POSIX_CONFORM=3D NOCONFLICT
>=20
> 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).=20
IMHO, nothing is not meaningfull in BSD nor nothing is meaningfull in Syste=
mV.
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 l=
ook
> a bit big and I'd like to see what later comes up wrt susv3 and patches t=
o 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.
--=20
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>