Why is procfs deprecated in favor of procstat?

[Martin Simmons]

>>>>> On Tue, 22 Feb 2011 23:14:44 +0200, Kostik Belousov said:
> 
> On Tue, Feb 22, 2011 at 01:10:57PM -0600, Bob Friesenhahn wrote:
> > On Tue, 22 Feb 2011, John Baldwin wrote:
> > >
> > >Actually, the replacement for procfs is not sysctl, but ptrace(2), and
> > >there
> > 
> > I have been following this discussion with my jaw agape.  It seems 
> > that the many men standing around this elephant are all perceiving 
> > completely different things based on their own interests and 
> > experiences.
> > 
> > My own software is using procfs to efficiently determine the path to 
> > the currently running executable.  I am sure that other software does 
> > the same since Linux procfs (and probably OS X) supports the same 
> > mechanism.  It is difficult to imagine how this would be done via 
> > ptrace(2).
> Look at the PT_VM_TIMESTAMP + PT_VM_ENTRY. You would iterate over
> the the mappings in the address space and look at the binaries at
> pve_path, if any. The one that is elf object f the ET_EXEC type
> is the binary. It is somewhat clumsy but the end result is the same
> as if reading /proc/<pid>/file.
> 
> Or, you use sysctl kern.proc.vmmap and get essentially the same data.
> PT_VM_ENTRY was added long after the sysctl, I did not objected exactly
> because ptrace(2) looked more logical.
> 
> The advantage of using procfs or sysctl instead of ptrace(2) is that
> you do not need to attach as debugger, causing the issues with signal
> delivery for the debugee.

Another advantage I find of (linux) procfs is that you always get a textual
version of it, which can be useful in shell scripts and debugging situations.

/sbin/sysctl kern.proc.vmmap isn't usable because the command has no way to
specify the pid.

/usr/bin/procstat gives access to only part of the procfs and sysctl
namespace.

__Martin