From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 14:42:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C269B106566B; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 73FF68FC17; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) Received: by dadv36 with SMTP id v36so7381191dad.13 for ; Tue, 26 Jun 2012 07:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7AJwgmKFOM7Eiohc/nf00x94+/bvifmzChfGE9/yWFU=; b=Z3ofc0dzwk38pQpaiVWljo3lEI+0jQDCZRi1BJncFk29DR2+jOP1Nt5h8mM7/23DID x7We2PdsQ9J9abP5/qdkGXiC4hhdy/cGBPs2JvAoNU5BgU1Oai7FRawhpJkyKj6x21Vk OyDpWESeiNa7XmBlt7OEW3l9hC4dKwpKU5BMk7zgJ/kFJw65LTgJTau618cMf4NJiZaZ bhBLQpeUHIO2scAcqqp0pYt8BS7iII5AiETo7uq9zyxHqvoHa2E0acL3M/awufePS4OD KbRX2rBoDaKoYiV0MzUN6R6zIWnVmK5E1jDB5lDoF8ZHMqT/h8QIICpSXWLk0igNxxBQ AjcA== MIME-Version: 1.0 Received: by 10.68.233.132 with SMTP id tw4mr52711220pbc.61.1340721756876; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 07:42:36 -0700 X-Google-Sender-Auth: x2biu1q5mqcvOmqUfYXD82T2AFo Message-ID: From: mdf@FreeBSD.org To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar , Chris Rees Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:42:38 -0000 On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote: > On Tue, 26 Jun 2012, Chris Rees wrote: > >>> as well as we don't depend of /proc for normal operation we shouldn't f= or >> >> say /proc/sysctl >>> >>> >>> improvements are welcome, better documentation is welcome, changes to >> >> what is OK - isn't. >> >> /proc/sysctl might be useful. =A0Just 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. =A0This c= omes > 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 e= ven > 8k buffers that might exist in a stock file access tool. =A0Unless we cha= nge > all of those tools to use buffers much bigger than they currently do, whi= ch > 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 cal= ls. > > 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 provid= e > this and other MIB-like properties, such as a basic data type model so th= at > command line tools know how to render content rather than having to guess > and/or get it wrong. =A0sysctl 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 fi= le > 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