Messages in this thread | | | From | "Adam J. Richter" <> | Date | Sat, 24 Oct 1998 16:02:18 -0700 | Subject | Re: ARMS WAVING!!! Proposal to fix /proc dainbrammage. |
| |
In article <Pine.LNX.3.91.981024070909.7978B-100000@mhw.ULib.IUPUI.Edu> Mark Wood writes: >[...] Perhaps much more important than >endianness or punctuation is once and for all settling the question of >whether /proc is for humans or for programs. ^^^^^^ ^^^^^^^^
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/
| |