On Thu, 24 Feb 2000, Glen Turner wrote:
>Ricky Beam wrote:
>> That is _exactly_ what /proc is supposed to be. Years ago when procfs was
>> just being introduced, that was it's sole purpose -- access to process
>> information without having to root through /dev/kmem to walk the process
>> tree in kernel space.
>
>So in positive terms, you're avocating a /parameter file system for
>those components of /proc that are not processes?
No. I'm advocating /proc (procfs in general as it can be mounted anywhere)
contain only the data for which it was designed: PROCESSES - period.
There shouldn't be one damned bit of english text in there anywhere.
The entire procfs was designed for accessing process table information
without looking directly through kernel memory. The pre-procfs method
was to lookup a kernel symbol (or be compiled with it) for the location
of the process table, open /dev/kmem (normally you'd need to be root to
do this), and then walk the task structure.
This is simply a "damned mess" -- as was explained to me a decade ago.
This method intoduces all kinds of problems ranging from parsing something
that isn't the process tree to getting half wrong results as the kernel
alters the table on you. At least under SunOS, 'ps' needed access to
the kernel you were running -- you've got access to /dev/kmem, might
as well have access to /vmunix too, eh.
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.
>> It has become nothing less than a run-down slum of the linux kernel. Every-
>> body and everything is buried in /proc and accessed via the stupidest and
>> most _inefficient_ mean imaginable.
>
>All operating systems are inefficient. Programming to the
procfs exists as an optimization of the way process information once was
handled because it was inefficient and difficult to manage.
Please do not try to preach you apathy to me. The whole "it's inefficient
anyway so why should _I_ try to be any better" arguement is a crock of shit.
To that I say, "Go back to writing JAVA and stay the hell out of the kernel.
Dammit, this is the _kernel_; it should even flush toilets with efficiency."
(Apathy breeds apathy; if you don't give a damn, nobody else will.)
>... And set/getting parameters via
>a filesystem space does this, as people writing in the
Umm, how in god name is sprintf(), copy (3 times), sscanf()/atoi() a better
way to read a number? If the only thing you know how to program is awk,
then maybe, but the real programmers use C. (I will accept C++ as an answer
but you only get half credit.)
>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.
>As a system monitoring tool can easily get another 10% out
>of a specific machine configuration, and magnitudes of performance
>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
for the .001% of the time that a human will be reading it is both inefficient
and stupid.
I think I've insulted enough kernel programmers for today :-)
My main problems with procfs:
1 - Most of it is designed for humans to read, however, humans never read it.
Programs are forced to parse english text to do anything. (kernel
sprintf()'s, program then sscanf()'s, processes, and printf()'s again.)
2 - /proc is the only point of reference to most of what's in it. Disable
procfs and practically nothing works.
3 - dependance on procfs (see #2) makes secured binary environments (i.e.
chroot()ed areas) difficult and impossible.
4 - the read() code path is a freakin' nightmare -- drive your kernel nuts;
read stuff in /proc one char at a time :-)
--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:09 EST