From owner-freebsd-current@FreeBSD.ORG Thu Jul 3 10:49:31 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9CA937B404 for ; Thu, 3 Jul 2003 10:49:31 -0700 (PDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA58A44003 for ; Thu, 3 Jul 2003 10:49:30 -0700 (PDT) (envelope-from msmith@freebsd.org) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h63HnRiB005561 for ; Thu, 3 Jul 2003 10:49:27 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com ; Thu, 3 Jul 2003 10:49:02 -0700 Received: from freebsd.org ([17.112.74.128]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h63HnHdi001482; Thu, 3 Jul 2003 10:49:17 -0700 (PDT) In-Reply-To: <20030703102627.D92002@root.org> References: <20030701103125.R87367@root.org> <3F021133.3040306@kasimir.com> <20030701164231.M88547@root.org> <20030703.052315.32736625.imp@bsdimp.com> <20030703102627.D92002@root.org> Mime-Version: 1.0 (Apple Message framework v578) Message-Id: From: Michael Smith Date: Thu, 3 Jul 2003 10:49:23 -0700 To: acpi-jp@jp.FreeBSD.org X-Mailer: Apple Mail (2.578) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: [acpi-jp 2381] Re: Updated ec-burst.diff patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 17:49:32 -0000 On Thursday, July 3, 2003, at 10:28 AM, Nate Lawson wrote: >> I personally think that all tunable should be read-only (or rw if >> possible) sysctls... > > I'm still not sure why we have both mechanisms. Perhaps a useful > approach > would be to sweep the tree for tunables and change them to sysctls with > appropriate permissions (read-only if in doubt). Then remove the > tunable > mechanism. Care to put together a patch? No. The two are different things, although arguably there should be more integration. The tunable mechanism exists to allow parameters to be set before the kernel starts. Things that are set with tunables tend to be things that used to be statically compiled into the kernel; they're not adjustable once the kernel's up and running. It makes sense to export the values set by tunables into the sysctl MIB, but by their very nature they're not suitable for conversion to sysctls. = Mike -- Where am I, and what am I doing in this handbasket?