From owner-freebsd-arch@FreeBSD.ORG Thu Jan 20 12:50:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79642106564A; Thu, 20 Jan 2011 12:50:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 316108FC1F; Thu, 20 Jan 2011 12:50:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9DAC046B09; Thu, 20 Jan 2011 07:50:08 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8BCE58A01D; Thu, 20 Jan 2011 07:50:07 -0500 (EST) From: John Baldwin To: mdf@freebsd.org Date: Thu, 20 Jan 2011 07:48:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101191559.07713.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101200748.49931.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 20 Jan 2011 07:50:07 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Weed-whacking sysctl(8) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:50:09 -0000 On Wednesday, January 19, 2011 6:18:09 pm mdf@freebsd.org wrote: > On Wed, Jan 19, 2011 at 12:59 PM, John Baldwin wrote: > > On Wednesday, January 19, 2011 3:28:19 pm mdf@freebsd.org wrote: > >> As bde@ mentioned, there's very little actual use of the sysctl format > >> strings. I recently changed it so the use is even smaller, but I've > >> got a quandary as to how to finish the job. > >> > >> I agree with Bruce that the formatted structs can just be removed. > > > > Hmm, I've actually used 'sysctl kern.clockrate' in the past. > > > >> This leaves just the "IK" format, which shows up in just a few files: > >> > >> sys/dev/acpica/acpi_thermal.c: > >> sys/dev/amdtemp/amdtemp.c > >> sys/dev/acpi_support/atk0110.c > >> sys/dev/coretemp/coretemp.c > >> sys/dev/iicbus/max6690.c > >> sys/dev/iicbus/ds1775.c > >> > >> I see two solutions to "IK". The first is to preserve the interface > >> as experienced by sysctl(8) users, and add some functions to push a > >> string buffer back to userspace, and parse a string in the kernel. > >> The second is to preserve the binary interface as experienced by > >> sysctl(3) users, and either have the values be dumped in the slightly > >> obscure 10ths of Kelvin values, or add a new CTLTYPE_KELVIN so > >> sysctl(8) can also keep showing things as it does today. > >> > >> Given how infrequent the use is CTLTYPE_KELVIN seems a non-starter. > >> So who is the worse client to break: those who use sysctl(8) to look > >> at temperatures, or those who have a utility to manipulate these > >> values using sysctl(3)? > > > > So what is sufficiently broken elsewhere that requires us to break the > > existing sysctls? Many people use the output of sysctl(8) for coretemp, and > > the ACPI thermal zones and breaking that gratuitously would be unfortunate. > > I've no idea if there is existing code reading these sysctls in userland for > > things like gkrellm, but I wouldn't be surprised if there were. > > The usage of the format string is (was) limited to sysctl(8) (as is > the ctltype), and more importantly it was being set inconsistently. > There is no way to check at compile-time if the format string is > correct. The two cons I see to this are 1) many scripts rely on the output of sysctl(8), and 2) jmg@ was actually talking about exporting the metadata via libc routines so that applications could begin to use them. > > Even CTLTYPE_KELVIN would require changes to user apps, but I also would > > rather present an actual number to userland rather than a string so userland > > doesn't have to parse it just to get back to the original number. > > At the moment, only sysctl(8) would require a change since no other > code knows about the ctltype. > > > I guess I fail to see why sysctl giving a hint about the semantic type of > > the data ("temperature", "struct foo") which is separate from the "physical" > > type (e.g. 32-bit or 64-bit) is such a bad thing. > > Except in a few circumstances, it's unused. There's a lot of "S,foo" > that is being ignored. Well, currently applications hardcode what certain sysctls are because that information is not exposed to userland. We could stick with applications having to hardcode that, but I do think that 1) the output of sysctl(8) for the temperature nodes has to be preserved due to existing scripts, and that 2) the raw data exported via sysctl(3) should be an int, not a string. I'm not sure how you can do that without some sort of hint to tag certain nodes as having deci-Kelvin units. Note that you could change the format string to not include type information. For example, it could just contain "K", or "X" (for hex), but not include "I" or "L" or "U". This avoids duplicating the CTLTYPE_* flags that you can't add compile time assertions for while leaving the semantic tagging. I think it would be ok to break the existing format strings so they only hold that sort of data which would let you not have to worry about them being out of sync with the CTLTYPE_* flags. -- John Baldwin