So, I'm going to use an old meeting tactic of saying, "let's look at
this from a higher level", and let's ask ourselves what the goal we have
of standardizing /proc? Each person making suggestions has been doing
so with their own goals in mind, which is not necessarily the same as
other people's goals. This makes the conversation very hard to follow.
What is it that you are trying to achieve? It is much better to address
it from a specific user problem statement --- the user needs to get
<this> information --- and then try to see if /proc is the best way to
get that information.
For example, if the user wants to get a process
listing, with 50 different options for how the fields should be
displayed, the user uses the ps program. This is generally considered
to be the superior solution over some crazy scheme where you cat magic
options to a /proc/pslisting/options file, and then cat
/proc/pslisting/info to actually get the ps listing. Sometimes (almost
always), having a user-mode program to do the display, instead of
increasing kernel bloat by putting things into the kernel, is the right
thing.
The point I am trying to make here is that /proc isn't necessary the
right answer for any and all problems. Some of the discussions I've
heard really make it seem like newbie woodworking students who have just
discovered the /proc hammer, and are runninig around trying to see how
many nails they can find. /proc isn't necessarily a good replacement
for setsockopt(). /proc isn't necessarily a good replacement for
/bin/ps.
Please, let's keep a little perspective on things. There are many more
tools that we can use to solve a problem than simply making arbitrary
changes to /proc.
- Ted