From owner-freebsd-current Fri Apr 24 01:01:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17711 for freebsd-current-outgoing; Fri, 24 Apr 1998 01:01:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA17704 for ; Fri, 24 Apr 1998 01:01:11 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id IAA28002; Fri, 24 Apr 1998 08:00:02 GMT Date: Fri, 24 Apr 1998 17:00:02 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: wollman@khavrinen.lcs.mit.edu, darrenr@reed.wattle.id.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_fw.c In-Reply-To: <199804240716.AAA10334@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 24 Apr 1998, Terry Lambert wrote: > 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"). Umm. Could it be done completely data driven without having to invoke routines out of the image? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message