5 Aug
2014
5 Aug
'14
8:41 a.m.
On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia(a)gmail.com> wrote:
On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman(a)oclsc.org> wrote:
<snip>
Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1)
and ptrace(2). I am still not too sure if it was the Right Thing(r)
to do though. The decision was more based on the premise that
procfs(4) was neglected in recent years than on anything else[0].
[0]
http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-p…
Everything has gotten more complicated. Some of
the complexity
involves reasonable tradeoffs (the move toward replacing binary
interfaces with readable text where space and time are nowhere
near critical, like the /proc and /sys trees in modern Linux).
<snip>
To digress from the main topic, I realize that's just one example, but
here's a counterpoint to it:
We in Solaris designed /proc as a tool for developers to build innovative
solutions, not an end-user interface. The Linux community believes that 'cat
/proc/self/maps' is the best user interface, while we believe that pmap(1)
is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M)
and a host of other tools all make use of this same information. It would be
a waste of time to take binary information in the kernel, convert it to
text, and then have the userland components all write their own (error
prone) parsing routines to convert this information back into a custom
binary form. Plus, we can change the options and output format of pmap
without breaking other applications that depend on the contents of /proc.
[ https://blogs.oracle.com/eschrock/entry/the_power_of_proc]