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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
