Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc | Date | Wed, 7 Nov 2001 02:20:35 -0500 (EST) |
| |
Alex Bligh - linux writes:
> What amuses me about those arguing for binary structures as a long term > solution for communicating, on a flexible but long lived basis, is that the > entire OS Genre they appear to be advocating (UNIX et al.) has been doing > this, on an app to app (as opposed to kernel to app) basis, for far longer > than most of them can remember, in situations where performance is far more > relevant, and pitted against far more 3l33t 5tud3nt2 than we we shake a > stick at, but /still/ they persist.
quotas, process accounting, wtmp, utmp, Tux web server logs...
> Through minor local idiocy, I had trashed my local lilo partition, > and had to try and boot with a Debian CD-Rom with a 2.2 kernel. I > forgot to ask for single user more. Not only did it boot first time, > it booted fully, apart from two minor things: no iptables, and > (shock horror) the sound card didn't work it wasn't compatible. > Similarly, I've loaded 2.4 kernels with no problems onto 2.2 systems. > > This "dreadful" /proc interface everyone talks about has been > *STAGGERINGLY GOOD* in terms of forward and backward compatibility. ... > has worked well just because kernel developers and maintainers > have showed themselves unwilling to break existing userspace > tools, and vice versa.
I can see that you are unfamiliar with the /proc filesystem.
You can change kernels because app developers work hard to be tolerant of stupid /proc changes. Some of the crap that I've stumbled across, mostly while doing procps work:
/proc/*/stat signal info was changed from decimal to hex for a while. I changed it back, but too late: the evil hex had already leaked out into the world, and I had to modify libproc. Quick, is 16785472 in decimal or hex? So use the "friendly" new /proc/*/status file instead, but...
The "SigCgt" in /proc/*/status wasn't always spelled that way. It wasn't always in the same location either, so what to do? That calls for another hack: assume signal values follow each other.
Kernel threads don't have memory info. Somebody added "kB" on the end of most lines in /proc/meminfo. /proc/stat has changed in ways that I'm glad to have forgotten. /proc/interrupts has been through a flood of horrid changes: the PIC type going from "" to "XT PIC" to "XT-PIC", the last column getting spaces (consider "XT PIC"!), a new header (just waiting for extra info) and a variable number of per-CPU columns in the middle to replace what was once a total. Maybe /proc/cpuinfo is the worst... I hear SPARC is pretty smelly, but hey, every arch screws app developers in some unique way.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |