From owner-freebsd-fs@FreeBSD.ORG Mon Feb 21 17:41:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0A64106566C for ; Mon, 21 Feb 2011 17:41:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0888FC0A for ; Mon, 21 Feb 2011 17:41:05 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id Aheg1g0040ldTLk53hh5Nv; Mon, 21 Feb 2011 17:41:05 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta04.westchester.pa.mail.comcast.net with comcast id Ahh21g0070PUQVN3Qhh3dV; Mon, 21 Feb 2011 17:41:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C9B7C9B422; Mon, 21 Feb 2011 09:41:00 -0800 (PST) Date: Mon, 21 Feb 2011 09:41:00 -0800 From: Jeremy Chadwick To: freebsd-fs@FreeBSD.ORG, kellydeanch@yahoo.com Message-ID: <20110221174100.GA77744@icarus.home.lan> References: <457880.36028.qm@web121501.mail.ne1.yahoo.com> <201102211707.p1LH7c8n075660@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102211707.p1LH7c8n075660@lurza.secnetix.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Why is procfs deprecated in favor of procstat? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 17:41:05 -0000 On Mon, Feb 21, 2011 at 06:07:38PM +0100, Oliver Fromme wrote: > Kelly Dean wrote: > > http://ivoras.sharanet.org/freebsd/freebsd8.html says that > > procfs is deprecated in favor of procstat. But Plan 9 says > > that procfs is the right way to do things. > > Linux says the same. But it's irrelevant what they say. > FreeBSD is not Plan 9, and FreeBSD is not Linux. > > Procfs has a long history of security vulnerabilities and > other problems. I do not mount procfs on most machines > I'm responsible for, especially not on machines that have > user accounts or services that are not restricted to jails. > > I also think it is inefficient to let the kernel render > data to ASCII, and then have userland tools parse that > ASCII data again. That's ridiculous. There is no sane > reason for putting kernel data as ASCII text into a pseudo > file system. I don't want to start a debate, but I disagree on the last point. If anything, the filesystem concept for data acquisition (from the kernel) most definitely falls under the "true UNIX way". I disagree with this data being made available under /proc, but I do feel what's provided as a simple file-based interface is the Right Thing(tm). Here's why: Programmers are strictly limited to the sysctl(3) interface, or get to do horrible things like fork()/exec() sysctl(8) repetitively for data. How efficient! Aside from C, I'm not aware of any programming languages that have native tie-ins to sysctl(3). I am explicitly excluding third-party modules for perl and other whatnots; they're silly. With a filesystem that provides sysctl data, you can literally use anything you want to get information: /bin/sh, python, perl, PHP, Tcl/Tk, Ruby, Java, or anything else. As it stands today, the programming language is effectively made retarded by repetitive calls to sysctl(8) to get data, check exit codes, not to mention the repetitive fork()/exec() requirements. For years now I have been considering a sysctl filesystem (e.g. mounted as /sysctl) which would solve this dilemma. Read-only might be a wise choice for this too. But this is beyond my skill set at this time, and the existing documentation/examples for a pseudo filesystem are really not that great. By the way, did you know present-day FreeBSD "ps -e" doesn't work? Try it and notice what the first line of output is. There are some other base system utilities that behave the same way (thing-X doesn't work without procps, and god forbid you use/mount it). I agree that procps should be removed, but the way this came about was obviously done in haste. Not cool. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |