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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:09 EST