"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.
> There's too much stuff in /proc. Much of it required for programs you
> would never expect would want to see what is historically process data.
In what way is this bad? Can you have too much information available?
Maybe ...
> procfs exists as an optimization of the way process information once was
> handled because it was inefficient and difficult to manage.
Remove the word "process" from "process information" (maybe replace
with kernel) and I'd agree with you. Nothing beats doing a cat
/proc/myinfo while developing a kernel driver.
Sure, if you're going to make that information part of a control loop,
you need something else.
> >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.
> >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
Unfortuately for your argument, humans are the ones processing the
information, ultimately.
> 1 - Most of it is designed for humans to read, however, humans never read it.
Untrue. Humans always read it, directly, or pretty nearly directly.
Anyway, it is clear that you are straying into the realms of language
design, where you have little experience!
> Programs are forced to parse english text to do anything. (kernel
And that's dead easy. What's your beef?
> 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.
> 2 - /proc is the only point of reference to most of what's in it. Disable
> procfs and practically nothing works.
Well, only ps fails that I know of!
> 3 - dependance on procfs (see #2) makes secured binary environments (i.e.
> chroot()ed areas) difficult and impossible.
Procfs has races and security problems. They should be addressed.
> 4 - the read() code path is a freakin' nightmare -- drive your kernel nuts;
> read stuff in /proc one char at a time :-)
That's only for the registered-my-function procfs files. As I recall,
the code dumps the whole splurge into a buffer again and then skips to
the right spot and reads back its character. 3000-1 inefficiency, with
races. The difficulty here is probably not this, but the fact that
the inner code doesn't know it's still talking to the same process
and doesn't need to recalculate anything. Heck, the fault is probably
yours for not buffering the output.
Peter
-
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