Date: Tue, 26 Jun 2012 09:59:27 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Chris Rees <utisoft@gmail.com> Cc: bp@freebsd.org, Arnaud Lacombe <lacombar@gmail.com>, freebsd-hackers@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, kby@freebsd.org, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Subject: Re: sysctl filesystem ? Message-ID: <alpine.BSF.2.00.1206260954120.2004@fledge.watson.org> In-Reply-To: <CADLo83_hLe-MUJASLmx%2B8MBj12LOQ_-gsmWNjpzvzZdxwEgStw@mail.gmail.com> References: <CACqU3MXaa0R7fG6Q-EqS3h8PJh__tzNeugBxVyqKHxsCR-wTuQ@mail.gmail.com> <alpine.BSF.2.00.1206260805450.3572@wojtek.tensor.gdynia.pl> <CADLo83_hLe-MUJASLmx%2B8MBj12LOQ_-gsmWNjpzvzZdxwEgStw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206260954120.2004>