"A month of sundays ago Ricky Beam wrote:"
> 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.)
I disagree. (a) humans are processes. (b), what's in a name? /proc has
come to mean "the place where the kernel outputs most of its info". Fine.
> called 'printk()' :-) What everyone is attaching to procfs is more aptly
> data for a kernelfs. (Yes, that's a BSDism.)
WHo cares what you call it? procfs? kernelfs? Sure, separate the
concerns if you feel like.
> >> 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
Well, set their permissions appropriately then. But the fact is that
the information has to be somewhere. How does being in proc in itself
somehow make the information less secure than in a file somewhere else?
> >> 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
Nonsense. Stop right there. Who cares what it was "developed for"?
There is no moral imperative that things Shall Be the Way They Were
Ordained to Be. The "was not developed for" argument is vacuous.
Human beings were not developed to fly, but they do.
> >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
Stop. You don't seem to grok "parsing is easy". That simply tells me
that you are one of the large number of programmers who can't write
parsers, and therefore think it is difficult. Your argument is false
from then on ...
> >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
Look, if I don't read the info, it's wasted. It might as well go to
/dev/null. So I can assure you that the only important use is for human
consumption. Proc's job is to facilitate my gathering of the information
I need. It does that in the classical spirit of language design, by
providing the information in convenient _readable_ formats. It's just a
lot of ascii info. Just like configuration files. Are you arguning for
a binary registry?
> >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
Pretty often. You don't seem to get that I read it every time I use a
tool that accesses it. I even read it without tools (except that some
of the formats are not very human readable, so I prefer not to ...).
> 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
You don't get the argument. Language design. You can write your code in
assembler, or in C, or in Python. /proc is there to provide the
interface that allows us to read the data with the minimum or
effort appropriate to a high-level interfaces: humans and
their scripts or minor programs. It's there to make life easy for US.
> >> 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
Why should I care if it takes 10ms or 20ms to cat a file from proc?
> to hunt for it in the text and then convert it from text to binary. THAT is
> my beef.
??? No it isn't. This is called parsing. It's easy.
>
> >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.
Embedded systems don't, by definition, have humans running them. And I
presume you in particular have no idea at all if your embedded system
is working correctly :-(.
> The human brain can parse text very effectively. Computers don't! Having
Computers are faster parsers. Perhaps you'd like the speed figures for
parsing a 10000 line fortran program on a 386sx20? I'd estimate between
10 and 30s. Beat that! (if you like, I'll measure something of the
sort, or dig out old figures of mine from about that era .. I seem to
recall it taking a few seconds at a time on the hp9000's)
> 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
Then in this case you happen to be a mistaken teacher. Doesn't matter.
I repeat ... parsing is easy. I'll add "fast", "efficient", too. Because
you don't seem to know that doesn't make it untrue! Check the
literature (some of it mine! Try looking for my stuff in Software
Practice and Experience about 95, and in TOPLAS too ...).
> >Well, only ps fails that I know of!
>
> Turn off procfs and you'll see... ifconfig, netstat, mount, modutils, kudzu,
Ifconfig doesn't fail. netstat might. mount still works. Modutils still
work (apart from lsmod).
> lmsensors, free, alot of sysconf()...
lmsensors won't work, by definition (In case you are wondering, yes, I am
typing this mail with /proc unmounted ;-).
> >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
I agree. It looks hard to tell the inner code which process is calling
it, but I don't think it has to be told. I'm almost sure that it's all
taken care of by the ordinary VFS layers. Yes. It is so. The only thing
that is not there is that there is no buffer in the interface between
VFS and the registered proc_info (or whatever) functions. Thus the
proc codes have to recalculate their data every time they are asked for
a bit of it, because they don't know how else to get to the wanted bit.
> 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)
It is a little hard, yes. It belongs in the proc API.
> 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
I sort of agree. Is it open and close that are the markers
you need? You need to maintain "process x has read up to here". I.e.
you need to maintain a page of output until all its current readers
have gone away. One can't tell what they might want to do next, ever,
so "close" is a reasonable signal to accept. Or you might choose to
expire the buffer after 1s unread and refresh the data. Nah .. that's
policy. You're right. Close is the signal to dump the buffer.
OK. I'll look at it.
> 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.)
>
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:10 EST