Messages in this thread |  | | Date | Thu, 30 Jan 1997 11:38:18 -0500 | From | (Aaron Tiensivu) | Subject | A couple "normal user" questions.. |
| |
Questions and ponderings:
I'm sure there is a reason for this being done, but I'm curious to what the explanation is to these "quirks":
/proc/sys/net /proc/net
It seems that maybe those two should be combined for consistancy.. I notice that /proc/net seems more "statistics" and /proc/sys/net is more "tunable" features. Is that the intent?
ip_forwarding is turned 'off' as default.. if you configure in 'IP_FORWARDING', shouldn't this probably be turned 'on' as default?
/proc/interrupts Any chance of Paul's patch to make 'unattached' interrupts say (not in use) instead of not showing up. Does this break too many already existing programs? [I noticed 'procinfo' didn't like it, but it was a quick hack away from doing the right thing]
/proc/ksyms The current state that this file is, it is basically useless as far as I can see. It doesn't contain all the references that System.map has. Was the original intent to be able to not keep around a System.map file and have it merely as a sym. link to /proc/ksyms?
I think the next suggestion won't go over too well, but please hear me out on this one. :)
RFC:
/proc/config
This would be simply the .config that was used in compilation of the kernel. I'm sure a lot of people have kernels lying around and they don't know what they compiled into it, and didn't keep the related .config around either. The reason I think it should be a /proc option is that it would be an easy reminder and a small portion of code.
That way.. for newbies to kernels, a userland program could parse /proc/config and tell them exactly what is configured into the kernel.
-- Which is worse: ignorance or apathy? Who knows? Who cares? "Nobody knows I'm a lesbian." -- seen on a guy's shirt Noah made a mistake letting people on the ark. Most of your faults are not your fault.
|  |