From owner-freebsd-arch@FreeBSD.ORG Wed Jan 19 23:22:10 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 A6073106566B for ; Wed, 19 Jan 2011 23:22:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5BADE8FC12 for ; Wed, 19 Jan 2011 23:22:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1382937iwn.13 for ; Wed, 19 Jan 2011 15:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3n2zuS4XlH8Xu0FRWM95pISI2bWlXzKL0AxcEqpvT/o=; b=YnCc0VC/cWpbsWQKgp4KJkzKte/botKC0VbSUkIYsWLo49w6WR9xETwNC2cEnNHCkP /jOdmhpwVhH0p1WcoOM/29yFvmMl/J0hXb/FPuYqzfnvqXu9hk2PqKmo5CACzvyPQfSC cKk5uI3zlT597nKkbpQp4kBVjyzbmL3wzjUCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oZ05VZadtxuviAfAPNl+WNZPWRMJZv+KV4ten3J/KZCVyoyPpvxUK9wh7A0Mm2lWLM OG8TqYJXbST2E2xfiXC63k/6ZGUWZHGid1P2wuuchyLsTIfU6sx8ZUYhvjKN/KBzQpfv aXbzo/12ADaj+q6I1lXWRxYXZ7w6XBg7TVCEo= MIME-Version: 1.0 Received: by 10.231.173.67 with SMTP id o3mr1667962ibz.29.1295479259223; Wed, 19 Jan 2011 15:20:59 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 19 Jan 2011 15:20:59 -0800 (PST) In-Reply-To: <20110119214339.GH66284@funkthat.com> References: <20110119214339.GH66284@funkthat.com> Date: Wed, 19 Jan 2011 15:20:59 -0800 X-Google-Sender-Auth: OBSLMuuP_8zsp7TIYgylNZdQLsY Message-ID: From: mdf@FreeBSD.org To: jmg@funkthat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 23:22:10 -0000 On Wed, Jan 19, 2011 at 1:43 PM, John-Mark Gurney wrote: > 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. =A0I 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". =A0The 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. =A0So only > preserving sysctl(8) output would be my vote. =A0(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. IMO it would be nice to have a real API to fetch the type. The sysctl documentation claims it's being thought about, but I think it's said that for several years. :-) The format string was mostly unused and I'd prefer it to die than be used more. Except for the case of "IK" and 4 specially formatted structs, the string provides no new information over the ctltype. Thanks, matthew