On Thu, 24 Feb 2000, Peter T. Breuer wrote:
>"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.
procfs is for process information (I'll be playing the part of purist today.)
If you want a kernel reporting facility, allow me to introduce a little thing
called 'printk()' :-) What everyone is attaching to procfs is more aptly
data for a kernelfs. (Yes, that's a BSDism.)
>> 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 ...
YES! Gee, let's give untrusted things access to /proc. There's all sorts
of "good stuff" in there. This can be quite a security problem. BUT, due
to the fact that some information cannot be gotten anywhere but /proc, you
have to give them access to it. (Metaphor warning) Would you let a stranger
into your home to use the bath room?
>> 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.
NO. procfs was design for PROCESS INFORMATION. Over the years, people have
attached non-process information in there. It's become the city dump for
any information one needs to get out of the kernel.
>> 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.
No it's not. That's one of the foundations of perl. I've seen (and even
written) some highly complex perl programs (yes, programs, not scripts)
that did all kinds of things with binary data structures. Most people
don't write _programs_ in perl; they write _scripts_ for doing a specific
task quickly. Any real programmer can do just as quickly in C what they
can do in perl.
But, we're arguing religions now. The point is, there's no reason to
condeme everyone to inefficient text processing for the few people who
refuse to write programs or deal with binary information.
>Unfortuately for your argument, humans are the ones processing the
>information, ultimately.
Wrong. Do some analysis of procfs accesses and you'll see most of the access
to procfs information is never seen by a human. (This excludes 'ps' information
as that's what's supposed to be in there _and_ it's mostly binary data in
the first place.)
>> 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!
Wrong. How often do you read /proc/net/dev? Granted, there are many things
in /proc that are often reprocessed for displaying to a human (netstat data
for one.) HOWEVER, that information is read as text, converted to binary,
processed, and then converted back to text and displayed.
Unless you intend on using 'cat' to view everything, my arguement stands.
(/proc/pci is about the only thing routinely 'cat'ed. However, there is
strong pressure to remove it in favor of a userland app to *gasp* process
the binary data -- of course, the "binary" data in /proc/bus/pci is presented
as text.)
>> Programs are forced to parse english text to do anything. (kernel
>
>And that's dead easy. What's your beef?
Easy != Efficient. And it's easier to read a number as a number and not have
to hunt for it in the text and then convert it from text to binary. THAT is
my 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.
Oh good god! Every programmer should be forced to program for an embeded
system for a day. Maybe then people would stop doing such stupid things.
The human brain can parse text very effectively. Computers don't! Having
taught computer science for a few years, I can tell you that's not
"convenient" for programmers. Most of the errors students make are in
processing human formated input. Converting data from a machine format
to a human format to only turn it back into a machine format is just
wrong.
>> 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!
Turn off procfs and you'll see... ifconfig, netstat, mount, modutils, kudzu,
lmsensors, free, alot of sysconf()...
>> 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.
chroot() _does_ address them. It also isolated applications from the rest
of the filesystem. Alot of chroot()ed things are done this way to
specifically to keep them away from /proc (and more importanyly "/")
>> 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.
It's not the individual driver's resposibility to keep up with it. What you
suggest is the replication of read() handling code for functions providing
data via procfs. NO. The correct place to put this is in the procfs layer
that calls the specific driver's read() function. I was amazed to see that
wasn't already done. And in fact, putting the handling in the driver is
hard to do correctly without introducing a memory leak. (or breaking a few
modules)
This is 100% the fault of procfs. Code needs to be placed in the open()
and close() functions for handling read()s without calling the driver's
function over and over again. The driver should then allocate sufficient
space for the data and return a pointer to it -- that's it for the driver.
procfs can chew on that buffer all it wants until close() or the app flushes
the fd. This is very clean, robust, and efficient. It also helps to close
a few potential races and increases kernel performance (altho' probablly not
measurablly -- as I recall, some of the /proc/net information spinlock()s
the kernel due to potential races.)
--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:10 EST