Messages in this thread | | | Subject | Re: [proc.txt] Fix /proc/pid/statm documentation | From | Albert Cahalan <> | Date | 06 Aug 2004 11:14:56 -0400 |
| |
On Fri, 2004-08-06 at 13:08, Roger Luethi wrote: > On Fri, 06 Aug 2004 10:02:28 -0400, Albert Cahalan wrote:
> > > what a good solution would look like. Files like /proc/pid/status > > > are human-readable and maintenance-friendly (the parser can recognize > > > unknown values and gets a free label along with it; obsolete fields can > > > be removed). > > > > If you're just spewing the values with a perl script, sure. > > I'm not sure this matters. > > It matters to me. I like to have tools that don't need updates to > cope with new fields. Having to wait for tool authors to catch up with > kernels is annoying.
Not many people want raw data, so the tool authors will need to put out new releases anyway.
It doesn't take more than a week generally.
> > If it's going to be this dynamic, then just give me DWARF2 debug > > info and the raw data. Like this: > > > > /proc/DWARF2 > > /proc/1000/mm_struct > > /proc/1000/signal_struct > > /proc/1000/sighand_struct > > /proc/1000/task/1024/thread_info > > /proc/1000/task/1024/task_struct > > /proc/1000/task/1024/fs_struct > > That's different. The overhead would be prohibitive. Also, this exposes > internal kernel structures.
The overhead? I'm not seeing much, other than the multiple files and the very fact that field locations are movable.
As long as I can fall back to the old /proc files when truly radical kernel changes happen, exposure of kernel internals isn't a serious problem.
If I had the DWARF2 data alone, /dev/mem might be enough. (sadly, "top" would require some major work before I'd trust it)
> > > Or use netlink maybe? It sure would be nice to monitor all processes > > > with lower overhead, and to have tools that can deal with new data > > > items without an update. > > > > I've been thinking netlink might be good. > > Alright. Maybe we can move our discussion into this direction?
I'll need to track down some netlink documentation. Last time I looked, there wasn't any.
> > > - Split proc information by new criteria: Slow, expensive items should > > > not be in the same file as information that tools typically > > > and frequently read. For instance, you could have status_basic, > > > status_exotic, and status_slow. Even status_basic could have a format > > > similar to /proc/pid/status, but would be shorter and contain only > > > the most frequently used values (like statm today -- with all the > > > problems that come with such a pre-made selection). > > > > Split by: > > 1. locking > > 2. security. > > Hmmm... How does this translate to a netlink interface? Can you elaborate?
I don't think it does.
For the existing files though:
Some SE Linux policies block all access to /proc. Some security feature patches zero out things that would reveal addresses. (start_code, end_code, wchan...)
- 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/
| |