From owner-freebsd-arch@FreeBSD.ORG Wed Jan 19 21:56:46 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 CF4A7106566B; Wed, 19 Jan 2011 21:56:46 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id A66C88FC13; Wed, 19 Jan 2011 21:56:46 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p0JLhd6p026419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 13:43:39 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p0JLhd4Y026418; Wed, 19 Jan 2011 13:43:39 -0800 (PST) (envelope-from jmg) Date: Wed, 19 Jan 2011 13:43:39 -0800 From: John-Mark Gurney To: mdf@freebsd.org Message-ID: <20110119214339.GH66284@funkthat.com> Mail-Followup-To: mdf@freebsd.org, FreeBSD Arch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 19 Jan 2011 13:43:40 -0800 (PST) Cc: FreeBSD Arch 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: Wed, 19 Jan 2011 21:56:46 -0000 mdf@freebsd.org wrote this message on Wed, Jan 19, 2011 at 12:28 -0800: > 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. > 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)? I've been watching this discussion pretty closely as I recently wrote a bsnmp module to export sysctl values and ran into the problem of parsing data exactly how sysctl(8) does it for presentation. What about creating a new SYSCTL_KELVIN that is SYSCTL_PROC that converts that variable in kelvin into 10ths of Kelvin, or as a floating point value? It would break people who were directly parsing sysctl(3) output, but they were also never quering the type via the undocumented API to get the correct format and type information in the first place and depending upon the undocumented type behavior. The man pages for acpi_thermal(4), amdtemp(4) and coretemp(4) only say that the temp is supplied by those sysctl nodes, not the format nor that they are in the magic 10ths of Kelvin formation. So only preserving sysctl(8) output would be my vote. (Preserving sysctl(3) users that properly understands format and/or type would also be best). I was about to write a patch to add a function to libc to be able to get both format string and type, but obviously this has changed a bit in the last week, and at least the format string part will not be necessary. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."