There isn't that much to be discussed there.
1. /proc is for process data becouse this has inherently a tree structure and
the FS abstractis is fitting this nicely. (We can share code with the VFS layer
2. /proc/sys is justifyed by the fact that sysctl can share a significant
amount of code with the procfs implementation. Note this *could* be changed
by abstracting the common code out of *both* procfs and sysctl instead
of stacking sysctl on to of procfs.
3. /proc/bus is superceeded by driverfs but has a tree struct and one can life
The rest is utter crap and legacy. Technically at least.
In particular the stuff listed above is looking like things which are in
reality device access abstractions and which belongs therefore to /dev/.
The only problem here is - people without taste for the implementation,
apparently love to look at files in /proc becouse this is giving them some
feelings I can't share...
PS. Did I mention that uniformity of interfaces is quite common in good
design practice? And something beeing ASCII simple doesn't imply that
it is an uniform interface.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/