From owner-freebsd-arch@FreeBSD.ORG Wed Jan 19 23:18: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 C8BB8106566B; Wed, 19 Jan 2011 23:18: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 810118FC1B; Wed, 19 Jan 2011 23:18:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1379780iwn.13 for ; Wed, 19 Jan 2011 15:18: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=B5wv9Yf5vnZM7aqRufisMxUSlxXpPLlrZrh1fVCoLlM=; b=yGqx1JAP8CMc1PBP6EZqRW+TxTxxN6LFlbV72HM9ot9pWa7K/NnRBIEE8SJp2o6Ahf dCul3aIMjE0CPLcL9cMAbx/G+88axVV8/zJpbWhof1K1JHudjiF2x3qkTqTZ98b2fdkt TB9tJ0ueDcH6J4ivb3nLDuImIaqyboftytsQg= 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=Hli6O3HwIvN5vE20nY08b2K0gl/5yJWs7rLIGkrprcQe0w5I/PC91xmxPjK7X0G+lm 7LAFk96JRJYORkfdu99w9phoLggtppa4udraTVQkiBh3EmS9XmH3I+TtxE2rKmjUluqk vFD1Aiju0D+H+oR+ZitoXzJSKwR5QHMGiz6pg= MIME-Version: 1.0 Received: by 10.42.171.70 with SMTP id i6mr1683018icz.322.1295479089896; Wed, 19 Jan 2011 15:18:09 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 19 Jan 2011 15:18:09 -0800 (PST) In-Reply-To: <201101191559.07713.jhb@freebsd.org> References: <201101191559.07713.jhb@freebsd.org> Date: Wed, 19 Jan 2011 15:18:09 -0800 X-Google-Sender-Auth: WEpXy2oVOpgrTQXMk9cq4ff8v1E Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 19 Jan 2011 23:18:11 -0000 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. =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. > > 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". =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)? > > So what is sufficiently broken elsewhere that requires us to break the > existing sysctls? =A0Many people use the output of sysctl(8) for coretemp= , and > the ACPI thermal zones and breaking that gratuitously would be unfortunat= e. > 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. > 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 userl= and > 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 "physic= al" > 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. Bruce I hope will chime in with his reasons. Thanks, matthew