From owner-freebsd-arch@FreeBSD.ORG Wed Jan 19 23:26:35 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 21F4D106564A; Wed, 19 Jan 2011 23:26:35 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0FC18FC14; Wed, 19 Jan 2011 23:26:34 +0000 (UTC) Received: by iyb26 with SMTP id 26so1318068iyb.13 for ; Wed, 19 Jan 2011 15:26:34 -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=Q03U5IjoPeHBVTxe6gsGc5WhwXbejqmDw3DF5zeOTIk=; b=icfNYyBSj0nKU/If/5y0bsldo9bBGwiD/TyTeFOf+iEUoFRASoAobeySgptlCpWiBq pSSCDOmKU3B/BauGH2+YTFoefHMfkDyRSkR+2jJm36FDzsFIEcg3DyB877Edl5gI5kNZ SNM0uf+YjVSf4kxWzJspc8eUxh7ukUEuH/IrA= 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=ixjpWllihVXOLUczaUuTr9yiWfhAJWA9TfeErIwO5+AwqE4WeXcOlsKaaLOUZcgnUe T3J1jjTOTaHkJ6oUFUHDAIin/L9kRDyEHso+SGStFypMXMtCAt6oPB3r6nT1kfApy7EL tW9hSmQ4q1ney8943FpLL9L7WnaIaYLliI0+4= MIME-Version: 1.0 Received: by 10.231.35.141 with SMTP id p13mr1652793ibd.79.1295479594333; Wed, 19 Jan 2011 15:26:34 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 19 Jan 2011 15:26:34 -0800 (PST) In-Reply-To: <20110119205445.GX21872@elvis.mu.org> References: <20110119205445.GX21872@elvis.mu.org> Date: Wed, 19 Jan 2011 15:26:34 -0800 X-Google-Sender-Auth: 9ROba8rG1nb_7-uusjnJYKphDyA Message-ID: From: mdf@FreeBSD.org To: Alfred Perlstein 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:26:35 -0000 On Wed, Jan 19, 2011 at 12:54 PM, Alfred Perlstein wro= te: > * mdf@FreeBSD.org [110119 12:28] 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. >> 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'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? Mostly because it's relatively unused, and except for three acpi_thermal instances it's read-only. I wasn't able to find any tools in the tree that knew what format these are in, and as someone else pointed out the units aren't part of any documentation either. > 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. So far I don't believe I have changed any KPI except for if someone had a custom handler for a QUAD. I would like to do so at some point as 99% of SYSCTL set-up uses OID_AUTO, and it should be 100% but for some legacy code. > 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". Existing uses of the standard SYSCTL_[ADD_]FOO can be made backwards compatible for a release or so, with minimal effort on my part. It makes the tree a little uglier for a while, though. I was involved with a FreeBSD merge at $WORK from 6.1 to stable/7 and there was a decent bit of change in there. For my part, I preferred a nice clean compile-break to something that still compiled but wasn't the right way to do things going forward. Thanks, matthew