From owner-svn-src-head@freebsd.org Mon Oct 9 12:54:36 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E732E2FD21; Mon, 9 Oct 2017 12:54:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id E5E3576B7A; Mon, 9 Oct 2017 12:54:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id A8ABB3C579D; Mon, 9 Oct 2017 23:54:32 +1100 (AEDT) Date: Mon, 9 Oct 2017 23:53:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sergey Kandaurov cc: Edward Tomasz Napierala , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r324427 - head/bin/ps In-Reply-To: Message-ID: <20171009231134.P2645@besplex.bde.org> References: <201710091024.v99AO6pt011672@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=bc8baKHB c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=UyfP_cosPN9UB4uMd_gA:9 a=tpJOXtjAOTdNX3We:21 a=mCOBi_0y4SuvmJo5:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 12:54:36 -0000 {Please ignore my previous null reply] On Mon, 9 Oct 2017, Sergey Kandaurov wrote: > On 9 October 2017 at 13:24, Edward Tomasz Napierala > wrote: > >> Author: trasz >> Date: Mon Oct 9 10:24:06 2017 >> New Revision: 324427 >> URL: https://svnweb.freebsd.org/changeset/base/324427 >> >> Log: >> Document "tdnam" keyword to ps(1), and add "tdname" alias. >> Modified: head/bin/ps/keyword.c >> ============================================================ >> ================== >> --- head/bin/ps/keyword.c Mon Oct 9 08:50:03 2017 (r324426) >> +++ head/bin/ps/keyword.c Mon Oct 9 10:24:06 2017 (r324427) >> @@ -201,6 +201,7 @@ static VAR var[] = { >> {"tdev", "TDEV", NULL, "terminal-device", 0, tdev, 0, CHAR, NULL, >> 0}, >> {"tdnam", "TDNAM", NULL, "terminal-device-name", LJUST, tdnam, 0, >> CHAR, >> NULL, 0}, > > Hello, > could you please fix this ^^ "tdnam" description as well? > fwiw, looks like it's only used in libxo as a field name. Since it is badly designed and implemented, 2 names for it are worse than for any other keyword. Perhaps since it was undocumented in the man page and misdocumented in the screen, nothing uses it and you can rename it without anything noticing it. (Design errors start with splitting thread and proc names in a way that is difficult for applications to untangle. Implementation errors start with abusing the space reserved for the old command name (ki_ocomm) for ki_tdname. This helps break old applications that only understand ki_ocomm. TDNAMLEN = OCOMMLEN = 16 is also too small, and its name is spelled without an E, unlike all other *NAMELEN names in . This is too short. It is only 3 shorter than COMMLEN, but should probably be longer, depending on how thread and proc names are split. The last bug has been partly fixed. There is now ki_moretdname[]. This has length just 3 (plus 1 for a NUL) to make allow expansion of thread names to the same length as proc names (19). ps and top actually understand this (except the update to use it is missing in ps/ps.c; it is only in ps/print.c). Thread names are also printed for the comm and command keywords in ps. They are essentially appended to ki_comm. This is too simple of ki_comm already contains some thread info. A negative amount of space is available for expansion. if the user uses tdnam then it is even more difficult to get a good combination of proc and thread info. Bruce