From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 08:59:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2219106566C; Tue, 26 Jun 2012 08:59:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 885928FC15; Tue, 26 Jun 2012 08:59:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 653D246B09; Tue, 26 Jun 2012 04:59:27 -0400 (EDT) Date: Tue, 26 Jun 2012 09:59:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chris Rees In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 08:59:28 -0000 On Tue, 26 Jun 2012, Chris Rees wrote: >> as well as we don't depend of /proc for normal operation we shouldn't for > say /proc/sysctl >> >> improvements are welcome, better documentation is welcome, changes to > what is OK - isn't. > > /proc/sysctl might be useful. Just because Linux uses it doesn't make it a > bad idea. One of the problems we've encounted with synthetic file systems is that off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but not unreasonable) assumptions about the statistic content of files. This comes up frequently with procfs-like systems where the size of, say, memory map data can be considerably larger than the perhaps 128-byte, 256-byte, or even 8k buffers that might exist in a stock file access tool. Unless we change all of those tools to use buffers much bigger than they currently do, which even suggets changing the C library buffer to defaults for FILE *, that places an onus on the file system to provide persisting snapshots of data until it's sure that a user process is done -- e.g., over many system calls. sysctl is not immune to the requirement of atomicity, but it has explicit control over it: sysctl is a single system call, rather than an unbounded open-read-seek-repeat-etc cycle, and has been carefully crafted to provide this and other MIB-like properties, such as a basic data type model so that command line tools know how to render content rather than having to guess and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better match for accessing this sort of monitoring and control data than the POSIX file API, and would recommend against trying to move to a sysctl file system. Robert