Re: [proc.txt] Fix /proc/pid/statm documentation

[Albert Cahalan]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/