Why is procfs deprecated in favor of procstat?

[Jeremy Chadwick]

On Mon, Feb 21, 2011 at 06:07:38PM +0100, Oliver Fromme wrote:
> Kelly Dean <kellydeanch at yahoo.com> 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 at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP 4BD6C0CB |