Messages in this thread | | | Date | Thu, 24 Feb 2000 12:24:26 +1030 | From | Glen Turner <> | Subject | Re: What /proc should contain [was: /proc/driver/microcode] |
| |
Ricky Beam wrote:
> That is _exactly_ what /proc is supposed to be. Years ago when procfs was > just being introduced, that was it's sole purpose -- access to process > information without having to root through /dev/kmem to walk the process > tree in kernel space.
So in positive terms, you're avocating a /parameter file system for those components of /proc that are not processes?
> It has become nothing less than a run-down slum of the linux kernel. Every- > body and everything is buried in /proc and accessed via the stupidest and > most _inefficient_ mean imaginable.
All operating systems are inefficient. Programming to the metal is always faster. OSs are meant to promote the efficientcy of *programming*. And set/getting parameters via a filesystem space does this, as people writing in the languages often used to construct GUI and system monitoring tools can easily handle text and files, and those programs don't need to run as root.
As a system monitoring tool can easily get another 10% out of a specific machine configuration, and magnitudes of performance out of clusters, I can't see why you're attempting to gain minor efficiencies at the API when the cost is making it harder to do system monitoring.
I do agree that the /proc namespace and some file formats are bad. But only because they make writing system monitoring tools harder.
Regards, Glen
-- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- Earth is a single point of failure
- 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/
| |