Ricky, a couple of comments.
First of all, just because /proc was originally just for processes
doesn't necessarily mean that putting other stuff there is *wrong*. You
seem to take it as self-evident that anything other than process data in
/proc is evil. Sorry, you can't do that; if you want to make that
argument, you actually have to justify it. Bloat is one way of
justifying it, but that has to be done comparing it to how big /proc
would be without such features, and comparing the cost of the features
(kernel size) with the benefits of that features.
Secondly, the ASCII versus Binary issue. This is very much a relgious
issue. I will note that the folks at Bell Labs (remember, the ones who
originally designed Unix?), have come to the conclusion that ASCII
parsing is the right thing to do, and so *everything* in Plan 9 uses
ascii commands to comomunicate with the kernel --- and this includes
setting things that we currently use setsockopt() for!
Why is this? Well, there is a school of thought --- which includes the
folks who originally invented Unix --- that says that the time it takes
to parse ASCII is well worth the benefits; especially since these days,
CPU's are so fast that the time it takes to parse ASCII is usually not
measureable, as long as it's not in a fast-running loop, which reading
configuration information or opening up TCP connections generally
aren't.
What's the advantage of using ASCII files? Well, you've complained that
people have been careless about making "spelling" changes to files in
/proc. That may be; however, there is a lot of experience which shows
that making backwards compatible binary structures is even more
difficult! Consider how much pain we've needed to go through each
time we've needed to modify the stat structure. This is pain that
simply doesn't exist in Plan 9, since they use ASCII text for
everything.
One can argue that perhaps Plan 9 took things too much to extremese, but
the basic principal holds. ASCII is actually better for making
compatible extensions in the data that you can send back. Of course,
this assumes a competent programmer! But if you don't have a competent
programmer, things will go downhill even faster if you're using binary
structures.
That at least, is one school of thought. You don't have to believe.
But you might want to think a bit before you start putting down everyone
who might disagree with you on this issue. There is a lot of careful,
thoughtful experience who believes differently than you do.
- Ted
P.S. One solution to all of this is the sysctl tree. I know some
people don't like this either (including Linus), but one nice thing
about sysctl is that it gives you both ASCII and Binary methods of
accessing the data. It's also a slightly nicer interface to program to,
but one of the problems of both sysctl and the lower-level /proc
routines is that there's a bunch of additional work that can be done to
make them easier for the programmer to use, and to factor out more code
into higher-levle routines. But that's an implementation issue.
-
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:14 EST