Messages in this thread | | | Date | Thu, 24 Feb 2000 04:13:53 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: What /proc should contain [was: /proc/driver/microcode] |
| |
Peter T. Breuer writes: > "A month of sundays ago Ricky Beam wrote:"
>> There shouldn't be one damned bit of english text in there anywhere. > > I disagree. procfs is the most important and useful reporting system > the kernel has.
I hope you actually wrote serious proc-using code. If not, you should not argue. I wrote the new ps, and I think /proc is a crawling horror.
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.
>>> languages often used to construct GUI and system monitoring >>> tools can easily handle text and files, and those programs >>> don't need to run as root. >> >> What? "system monitoring tools"? You're perl scripts can do practically >> everything a C program can do including processing binary data structures >> and making system calls (ioctls, etc.) -- don't tell me otherwise because >> I've done it many times before. > > But this is wrong ("evil"). They should't. Parsing is easy. Let them > parse. Binary structures are for C.
Parsing kernel data is evil. The native format is binary. Parsing is something you do for human-supplied data.
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.
>>> out of clusters, I can't see why you're attempting to gain minor >>> efficiencies at the API when the cost is making it harder to >>> do system monitoring. >> >> 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.
> Unfortuately for your argument, humans are the ones processing the > information, ultimately.
Nope, most /proc access is does via programs written in C. Humans are not happy with one kernel-supplied output format.
>> Programs are forced to parse english text to do anything. (kernel > > And that's dead easy. What's your beef?
ROTFL!!!
The /proc/*/status keyword SigCat was changed to SigCgt. This is fine for a human, but programs shouldn't have to deal with this. Plain text in /proc costs you both reliability and performance.
>> sprintf()'s, program then sscanf()'s, processes, and printf()'s again.) > > So what? Who cares. It's supposed to be convenient. If that's what it > takes to be convenient, that's what it takes.
NO. The kernel API is not supposed to be "convenient" for humans. The kernel API should not even be POSIX. The kernel API should be as fast as possible. It should efficiently support POSIX, Java, and even Win32. The C library should hide the kernel API, and there should be tools that humans can use.
- 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/
| |