That is a false dichotomy. /proc is aimed at scripts (a type
of program) and, to a lesser degree, system administrators (a type of
human) and programmers.
/proc enables programs that may be as simple shell scripts to
access all kinds of obscure kernel data in a concise, obvious and
easily debuggable style without necessarily needing a layer of C
library calls and helper programs, using the strategy of putting
everything in text formats designed to be as easy as possible to parse
by programs and viewed by system administrators. The rise of "scripting"
languages shows that this approach ends up being beneficial to a wider
range of programs and users than one would initially think, because it
enables more or better software to be produced from a given amount of
effort, or enables software to be produced faster.
/proc is not all things to all people. There are many cases
where some sort of direct system call interface should be offered
instead of or in addition to a /proc interface, due to the complexity
of data or throughput issues.
As this logic applies to data formats, I think the data
formats exported by /proc should be as close as possible to the
command line arguments or external data formats used by related
programs. So, /proc/mounts looks like /etc/mtab, internet addresses
should be in dotted quad notation, etc.
I think most people would agree that the simplest and most
maintaintable formats for shell scripts and similar programs are
locale independent, byte order independent, arbitrary precision,
trivially parsible text with one record per line, all lines having the
same format, except for possibly one or more well defined preamble
lines that are trivial to skip.
-- Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/