From owner-freebsd-arch@FreeBSD.ORG Tue Apr 7 07:11:22 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D50F92DE for ; Tue, 7 Apr 2015 07:11:22 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 67EB2D23 for ; Tue, 7 Apr 2015 07:11:21 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id CA0FCD4799C; Tue, 7 Apr 2015 17:11:11 +1000 (AEST) Date: Tue, 7 Apr 2015 17:11:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chris Torek Subject: Re: sysctl output formatting In-Reply-To: <201504062229.t36MTMlJ024359@elf.torek.net> Message-ID: <20150407144043.W1410@besplex.bde.org> References: <201504062229.t36MTMlJ024359@elf.torek.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=1zTvKlfEcTyH67yu42YA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 07:11:23 -0000 On Mon, 6 Apr 2015, Chris Torek wrote: > We had a side discussion at $work about a private sysctl emulation > (so our side thing doesn't actually affect sysctl itself at all) > where it was suggested that some simple numeric sysctls are "best > displayed in hex". > > Consider, e.g.: > > $ sysctl kern.timecounter.tc.i8254 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 25822 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > > The "mask" here actually makes more sense displayed in hex. One > can of course use: > > $ sysctl -x kern.timecounter.tc.i8254 > kern.timecounter.tc.i8254.mask: 0x0000ffff > kern.timecounter.tc.i8254.counter: 0x0000786c > kern.timecounter.tc.i8254.frequency: 0x00000000001234de > kern.timecounter.tc.i8254.quality: 0000000000 > > but now the mask is shown in hex (yay) but the others are shown > in hex too (boo). > > The suggestion made (note that I'm carefully filing off names via > passive voice :-) ) is that there could be a sysctl flag: > > #define CTLFLAG_DEFHEX 0x00000800 > > that says that, without any additional formatting directive, the > user-level "sysctl" command should output this particular value in > hex. Obviously this eats up another flag bit (but there are a few > left) and might require a new argument to the sysctl command > ("force output to be decimal", for compatibility or whatever). The format arg still exists. It used to be used to get unsigned and hex formats, but is redundant for unsigned format and was rarely used to specify hex format. Now it seems to only be used: - for input, to distinguish between "IK" and other formats for CTLTYPE_INT. ("IK" with other CTLTYPEs is only supported for output) - for output, to support 'K' and even more unparsable formats like "S,clockinfo" and "S,vmtotal" Getting hex format for a single special sysctl would have been almost trivial when the X flag in the format was supported. Special cases tend to need specially bloated dynamic attachment that needs 1 byte to be changed to change the format string. For the example with timecounters above: X SYSCTL_ADD_UINT(NULL, SYSCTL_CHILDREN(tc_root), OID_AUTO, X "mask", CTLFLAG_RD, &(tc->tc_counter_mask), 0, X "mask for implemented bits"); SYSCTL_ADD_UINT() defaults a couple of parameters. Not enough to make it less bloated, but enough to prevent you controlling its format string. X SYSCTL_ADD_PROC(NULL, SYSCTL_CHILDREN(tc_root), OID_AUTO, X "counter", CTLTYPE_UINT | CTLFLAG_RD, tc, sizeof(*tc), X sysctl_kern_timecounter_get, "IU", "current timecounter value"); Here it is trivial to change "IU" to "IX". X SYSCTL_ADD_PROC(NULL, SYSCTL_CHILDREN(tc_root), OID_AUTO, X "frequency", CTLTYPE_U64 | CTLFLAG_RD, tc, sizeof(*tc), X sysctl_kern_timecounter_freq, "QU", "timecounter frequency"); This should use SYSCTL_ADD_UQUAD(). (The only differences are that it doesn't falsely claim to be MPSAFE, and has a garbage size value. Neither is MP safe on 32-bit arches, and the Giant locking given by not claiming to be MPSAFE doesn't give any safeness for the 64-bit variable accessed. The garbage size value is apparently unused. The similar x86 machdep.tsc_freq sysctl has a garbage size value of 0, but this seems to work too. In old versions, larger inconsistencies in the types and sizes caused garbage reading the top 32 bits, but also made it impossible to write these bits. SYSCTL_*PROC() is harder to use than SYSCTL_*INTTYPE(), but using it to specify a special ctltype or format is easy enough for a few uses. Bruce