Re: sysctl filesystem ?

On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson <rwatson_at_freebsd.org> wrote:
> 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.

While I understand the problems you allude to, the sysctl(8) binary
can protect itself from them.  IMO the biggest problem with sysctls
not being files is that it makes no sense from the core UNIX
philosophy that everything is a file.  Sockets and pipes and character
devices and even unseekable things like stdout are files; why aren't
these other objects that allow read, write, and have their own
namespace?

Cheers,
matthew