sysctl filesystem ?

[Robert Watson]

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