>My take on this is that all information in /proc should be available
>from sysctl() or some other similar method. The contents of /proc
>should be human readable. For scripting purposes, I'd have a userland
>program (called sysctl?) that's simply a wrapper around the appropriate
>calls to sysctl(). That way, the human readable output of /proc could
>be changed as appropriate without affecting programs that rely on the
>information (which would be using the "official" interface, the sysctl
>userland program, which wouldn't change).
>Yes, starting a new process is a higher cost than simply reading a
>file in /proc, but if you wanted performance, you wouldn't be scripting.
This program would have to be changed with every change in the kernel,
including additions of third party modules. Most items in /proc are
not read often enough to have any client programs that would
benefit from the faster access via sysctl when weighed against the
complexity cost. In addition, the CPU cost involved in exec'ing this
program for every read by the user program would be orders of
magnitude higher than the overhead of parsing fields in /proc.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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/