Skip site navigation (1)Skip section navigation (2)
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>