From owner-freebsd-arch@FreeBSD.ORG Thu Jan 20 08:38:38 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 595CF106566C; Thu, 20 Jan 2011 08:38:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id D922D8FC0A; Thu, 20 Jan 2011 08:38:37 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0K8cXPn030172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 19:38:35 +1100 Date: Thu, 20 Jan 2011 19:38:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <201101191559.07713.jhb@freebsd.org> Message-ID: <20110120190703.H11630@besplex.bde.org> References: <201101191559.07713.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@freebsd.org, 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 08:38:38 -0000 On Wed, 19 Jan 2011, 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. But you would have found it easier to use if its output were kern.clockrate.hz: 100 kern.clockrate.tick: 10000 kern.clockrate.profhz: 1024 kern.clockrate.stathz: 128 instead of kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } , no? Even more so for use in a script, say hz=$(sysctl -n kern.clockrate.hz) # can't do this now. The old clockrate sysctl would be retained for binary compatibility, but need not have special support in sysctl(8). The new sysctl would have to have a different name, but `clockrate' isn't such a good name anyway (`tick' isn't a rate, but the inverse of a rate, i.e., a time. However, it is closely associated with `hz' so it should be in the same sysctl tree, perhaps kern.clock.) >> 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)? Special formatting for these in sysctl(8) was a mistake, but I think have a special CTLTYPE to keep indicating that these are temperatures is very easy, especially since it is used infrequently. Also, it's not Kelvin, but deci-Kelvin :-). > 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 only want to remove the format strings. This saves checking that they are consistent with the data types, and some space. > 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. Hopefully thes is none using the format string except sysctl(8). sysctl(8) has to use intentionally still (?) undocumented sysctls even to read the format string. Other applications just need to know what sysctls returning degrees in deci-Kelvin actually are. They should have no difficulty knowing that the format is deci-Kelvin. > 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. > > 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. Note that this is not done for newer sysctls like kern.cp_time and kern.cptimes. The latter is especially cryptic since it doesn't even have delimiters for each CPU. Please keep them that way :-). (I have occasionally used kern.cptime output and had to stare at it to make sense of it. Dividing it by stathz would have been only a small help. I needed differences of it and ran a filter to get them.) Converting deci-Kelvin to Kelvin is relatively trivial. So is converting to Centigrade. But many would prefer Fahrenheit, or a GUI representation... The fancy presentation belongs in specialized apps. Bruce