info on /proc filesystem

info on /proc filesystem

Post by Hoa Nguye » Wed, 15 Apr 1998 04:00:00



Hi,

Does anyone know where I can find more detail information on the /proc
filesystem?

Thanks.
Hoa.

 
 
 

info on /proc filesystem

Post by Brian McCaule » Wed, 15 Apr 1998 04:00:00



> Does anyone know where I can find more detail information on the /proc
> filesystem?

No.  The answer to this question is necessarily "no".  You could have
worked this out before posting it.

You do not say what information you have already so how can anyone
possibly know that the information they know about is more detailed?

There's some info in /usr/src/linux/Documentation.

There's some in the proc manpage.

There's a lot scattered in comments in the kernel sources.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/


 
 
 

info on /proc filesystem

Post by J. S. Jense » Fri, 17 Apr 1998 04:00:00




> > Does anyone know where I can find more detail information on the /proc
> > filesystem?

> No.  The answer to this question is necessarily "no".  You could have
> worked this out before posting it.

> You do not say what information you have already so how can anyone
> possibly know that the information they know about is more detailed?

Heaven forbid someone might just answer a question instead of feeling
insulted by someone else's lack of knowledge and saying what is above.  Did
he*on your parade?  Why do you feel you must knock him?  I guess I am
being hypocritical here, sorry :-)

That is for what newsgroups are:  discussions and asking questions.  And I
just don't want them to become too hostile to someone asking an innocent
question as they seem to more and more often moving in that direction.

J. S. Jensen

 
 
 

info on /proc filesystem

Post by Brian McCaule » Sun, 19 Apr 1998 04:00:00





> > > Does anyone know where I can find more detail information on the /proc
> > > filesystem?

> > No.  The answer to this question is necessarily "no".  You could have
> > worked this out before posting it.

> > You do not say what information you have already so how can anyone
> > possibly know that the information they know about is more detailed?

> Heaven forbid someone might just answer a question instead of...

You appear to have overlooked the fact that I *did* answer the
question he actually asked.  The question was "Does anyone know...?".  
The answer to that question *is* "No".

So you think I should have just left it at that?  I think that would
be unhelpful to say the least.

I then went on to explain why the answer was "no", how he could have
improved his chances of getting useful responses and finally gave him
my best guess at the answer to the question he really meant to ask.

Quote:> ...feeling insulted by someone else's lack of knowledge and saying
> what is above.

If I feel insulted it is not at lack of knowledge it's at lack of
thought.  When you post a simple question to Usenet, orders of
magnitude more man-minuites are spent reading and responding to the
question than it took to compose the question.  If people can't be
bothered to invest a few extra second reading their questions and
thinking "have I given sufficient information so that it is actually
possible that anyone could answer this question?" then their actions
are insulting to all who read the group.

Quote:> Why do you feel you must knock him?

To help him.

Quote:> That is for what newsgroups are:  discussions and asking questions.

Yes but they are not like small face-to-face meetings or IRC.
Newsgroup discussion in a techincal newsgroup should be "tight".  With
so many participants all are under a m*obligation to think before
they hit send.

Quote:>  And I just don't want them to become too hostile to someone...

Hostile, who's being hostile?  I think it is *you* how need to lighten
up.

Quote:> ...asking an innocent question...

I do not consider this question to be "innocent".  He is guitly of
posting without thinking.  Not a serious crime but enough to warrant a
bit of friendly ribbing.

Quote:> ...as they seem to more and more often moving in that direction.

I don't think the atmostphere on Usenet is changing.  "Ask a silly
question, get a silly answer" has long been one of the guiding
principles.  I've asked my fair share of silly (or lazy) questions and
got my fair share of silly (or impatient) answers.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://www.veryComputer.com/~bam/

 
 
 

1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. New Configure script (and some console patches)

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. Problems With Large Memory.

5. /proc filesystem

6. Linux Partition seen under win95

7. Getting interface IP addresses with proc filesystem

8. Signals

9. filesystem status in proc?

10. Mounting proc filesystem dup2: Bad file descriptor

11. proc filesystem

12. proc filesystem?

13. Why does 'tar -clf' archive /proc filesystem?