From owner-freebsd-arch@FreeBSD.ORG Wed Jan 19 21:13:45 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 6102E1065670; Wed, 19 Jan 2011 21:13:45 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4088FC19; Wed, 19 Jan 2011 21:13:45 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id EBB5B1A3C49; Wed, 19 Jan 2011 12:54:45 -0800 (PST) Date: Wed, 19 Jan 2011 12:54:45 -0800 From: Alfred Perlstein To: mdf@FreeBSD.org Message-ID: <20110119205445.GX21872@elvis.mu.org> 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 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:13:45 -0000 * mdf@FreeBSD.org [110119 12:28] 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. > 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'd say that it's not great to break either system. The reason is that either the syscall or cmd line utility can be the basis of numerous system monitoring tools. By breaking either interface we discourage people from using it. I apologize for coming in so late, but why is CTLTYPE_KELVIN such an awful thing? Also, not to digress, but it sounds like there's a rototilling of the KPI going on here as well that might break 3rd parties who do their own monitoring software. Overall it's not a big thing, but when you consider all the changes like this that go on, it can add up to a discouraging target to track. Honestly I don't have a strong opinion on this and feel free to use your best judgement and as well as what other people bring to the table, I just wanted to bring the software churn issue up and leave the question, "is there a way to do this with minimal 3rd party breakage". thank you, -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer