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.