Messages in this thread | | | Date | Thu, 24 Feb 2000 13:29:08 -0500 (EST) | From | Ricky Beam <> | Subject | Re: What /proc should contain [was: /proc/driver/microcode] |
| |
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/
| |