>>> (My take on this question is that programs should not be looking
>>> in /proc at all; everything shown there should be available in
>>> binary form via syscall,
>> Oh yes! I really hate to parse /proc files. Parsing is not at all
>> reliable, considering unexpected format changes and spelling
>> fixes.
> That's not the fault of the /proc filesystem, but of the people
> who promiscuously change the format of entries there without
> considering the consequences.
Having had a look through all the files in /proc on my system, I can
see what Linus means by his comments about its needing to be cleaned
up, and I'd be interested in having a go at doing so.
Unfortunately, I have to admit that I don't have the foggiest how the
said filesystem works at the moment, so wouldn't be much use at this
stage, at least not unless somebody gave me some clues...
If there's anybody willing to help me here (PRIVATE email ONLY
please), then let's start with a simple question: What does the kernel
do in response to the following command - and, more importantly, which
kernel source files have the relevant code in them:
Q> cat /proc/net/route
As for the problem re whether these files should be ASCII or Binary,
there are two possible solutions to that, namely:
1. If it's passed through to the kernel, make use of the RAW flag to
fopen to indicate which format to return, with RAW == BINARY.
2. Have the /proc filesystem return TWO names for each file, one
giving ASCII text and the other giving binary fields. One version
of this would be for the binary version to consist of the name of
the ASCII version with a dot prepended to it, thus hiding those
from the listings that users would normally see...
However, that's not something I'd decide, not least because I don't
have any authority for making such a decision...
Best wishes from Riley.
-
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/