Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Apr 1998 07:16:44 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        michaelh@cet.co.jp (Michael Hancock)
Cc:        wollman@khavrinen.lcs.mit.edu, darrenr@reed.wattle.id.au, current@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/netinet ip_fw.c
Message-ID:  <199804240716.AAA10334@usr09.primenet.com>
In-Reply-To: <Pine.SV4.3.95.980424110909.25399B-100000@parkplace.cet.co.jp> from "Michael Hancock" at Apr 24, 98 11:10:24 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > > There are numerous programs like this already - ps, netstat, top, etc.
> > > I'd say "deal with it".
> > 
> > When I'm done with netstat, I hope to have its interface completely
> > separated from the actual kernel internals.  It's not there yet, but I
> > think I have the right ideas on how to proceed.  There's no reason why
> > the same strategy can't be taken with the process table.
> 
> I haven't looked at this but wasn't this a eproc-only vs. 
> eproc-with-entire-proc issue? 

Not really.

The "ps problem" is wih the -M, -N, and -W arguments; from the man page:

     ps [-aCcehjlmrSTuvwx] [-M core] [-N system] [-O fmt] [-o fmt] [-p pid]
        [-t tty] [-U username] [-W swap]

That is, "ps" operates on system dumps as well as running systems.

A procedural interface rather than a data interface won't work on a
system dump (since there is no kernel to service the method invocation).

The best implementation I could come up with was to make an abstract
data interface using a procedural access, and then bind the procedural
access to the kernel image (-N system).

The way this would work is that the "ps" program would dlopen() the
"system" image to access the procedural routines that operated
against the kmem image (/dev/kmem or "core").

This pretty much *requires* the use of ELF segments to be able to
seperately attribute what are, in effect, "file forks" in the kernel
image.

The other alternative is to make a "data accessor switch", and use
the existing routines against system dumps (assuming that the dump
and the particular ps build match, much the same way as we assume
that the running kernel and the ps build match today).  The "switch"
would use /proc if the -M/-N/-W were omitted.

This is a very unsatisfying soloution, for (I hope) obvious reasons.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804240716.AAA10334>