Let me preface my comments with a great big, loud
"AMEN BROTHER!"
On Thu, 24 Feb 2000, Albert D. Cahalan wrote:
>My fix would be to add the exact same binary files that Solaris has
>and to make all non-process information invisible. The filesystem
>code could also be used for /sys or /kern, with a mount option to
>show everything but the processes.
Well, not _exact_ ... ls -l /proc/<pid>/fd resolving to devices and filenames
is _very_ handy.
>I'd love to have the binary structures for C. In spite of being
>100% C, "top" can use 50% of my CPU time. Real code is C anyway.
Ok, so when did the non-procfs interface for process data go away? (I'm
assuming _years_ ago. There _were_ syscalls for it at one point.)
>>> The data should be structured efficiently for those things that will be
>>> accessing it. Human readable text is the worst possible input to any
>>> computer program. Structuring data such that a human can read it directly
>
>Damn right. BTW, some people feel a need to tweak the format!!!
>Parsing assumptions get blown away when somebody does something
>weird to the data, like adding whitespace where there was none
>or changing the spelling of keywords in /proc/*/status.
How many people remember the flaming weeks when meminfo changed? That is the
only patch I have ever seen backed out of the kernel tree!
>... Plain text in /proc costs you both reliability and
>performance.
Wasn't that one of the points in favor of procfs? (i.e. reliability via
isolation from kernel task structure changes.)
--Ricky
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:10 EST