From owner-svn-src-head@freebsd.org Mon Mar 13 01:37:20 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 6C08DD08719 for ; Mon, 13 Mar 2017 01:37:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id F40CE121A; Mon, 13 Mar 2017 01:37:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id DD978D43E10; Mon, 13 Mar 2017 12:16:09 +1100 (AEDT) Date: Mon, 13 Mar 2017 12:16:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ngie Cooper cc: Ian Lepore , Pedro Giffuni , Lawrence Stewart , src-committers@freebsd.org, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , svn-src-head@freebsd.org Subject: Re: svn commit: r314780 - head/lib/libpam/modules/pam_exec In-Reply-To: Message-ID: <20170313110832.H1060@besplex.bde.org> References: <201703061545.v26FjkNI027057@repo.freebsd.org> <739617a4-3eed-28d1-73e4-86d25d6d5fed@freebsd.org> <1839903b-fb05-bf3f-17bb-697afca9ecb7@FreeBSD.org> <1489341856.40576.88.camel@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=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=n-9ZFgpRNMLjgGdWWi0A:9 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, 13 Mar 2017 01:37:20 -0000 On Sun, 12 Mar 2017, Ngie Cooper wrote: >> On Mar 12, 2017, at 11:04, Ian Lepore wrote: > > ... > >> A quirk of C that's often forgotten is that a function-like macro is >> only expanded as a macro if the token following the macro name is an >> open paren. So nitems() is a macro invokation and nitems = 0; is just >> a variable. Perhaps it was a quirk in some pre-C90 compilers, but it is now intentional. >> I'm not arguing against the replacement of variables named nitems, I >> actually think that should have been done as part of importing the >> function-like definition of nitems from netbsd. I am arguing against it. Changing the it in the application would be punishing the application for the system stealing the application's namespace with undocumented pollution. > Minor correction (as Pedro noted later): > - NetBSD uses __arraycount. > - OpenBSD uses nitems. > FreeBSD has standardized on nitems, probably because it came about in 8.x, whereas __arraycount came about later. Good for NetBSD. __arraycount is not pollution and is clearly unusable in applications, at least when undocumented, since its name is reserved for the implementation. BTW, I lost the mail about churning HZ. Neither HZ or Hz is correct. HZ is only a bad name for the compile time default for the frequency of "clock ticks". The runtime frequency of "clock ticks" has the bad name "hz". The comment is trying to describe the latter. That is wrong too (see below). These names are bad because the name of a variable holding a freqency, or even the value of the variable, are very different from the units of the variable. "clock ticks" at the frequency of the misnamed variable "hz" are partly virtual now. On modern x86, there is no periodic clock, but one running at frequency hz is faked. The comment is trying to refer to this clock. But this is not the clock controlling the accuracy of the so-called "HZ" timestamp precision (TSP_HZ_. When hz is too large, the virtual clock ticks at frequency hz are scaled down by a factor of tc_tick that is larger than 1. This gives an accuracy of about 1/(hz/tc_tick). /sys/kern doesn't have many conflations of units with values under the spelling HZ (I think it has lots under the spelling hz; these are hard to avoid since the variable hz sometimes gives the correct frequency): - kern_poll.c says HZ=1000 in a comment (it means something like hz=1000) - sched_ule.c has a conversion macro named SCHED_TICK_HZ (it means from ticks in local units to ticks at frequency hz) - subr_param.c copies the bad example set by the config parameter HZ for HZ_VM - vfs_subr.c has 2 instances of HZ which should be (hz/tc_tick), and 2 instances of TSP_HZ. The sysctl for tc_tick has an incomplete description. It says that tc_tick is the "Approximate number of hardclock ticks in a millisecond". This is a bit verbose, but it avoids conflations with Hz and complications with the hz variable and units errors for "milli". But the stated approximation is impossible when hz is much smaller than 1000. Then tc_tick is 1. The sysctl is read-only, so users can't modify the scale factor to get more accuracy from TSP_HZ, etc. The implementation depends on hz/tc_tick being not much larger than 1000 (to work on slow or high latency systems) and tc_tick is chosen to give this. So description comment remains correct if it was correct originally. It is still simpler to describe this as a scale factor. It is not useful for users to know that this variable holds the stated value (except when it doesn't). It is useful for them to know that it scales the accuracy of hardclock ticks in some cases. Bruce