From owner-freebsd-current Fri Apr 24 01:39:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22974 for freebsd-current-outgoing; Fri, 24 Apr 1998 01:39:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA22953 for ; Fri, 24 Apr 1998 01:39:27 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id BAA08294; Fri, 24 Apr 1998 01:39:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd008268; Fri Apr 24 01:39:17 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id BAA23279; Fri, 24 Apr 1998 01:39:12 -0700 (MST) From: Terry Lambert Message-Id: <199804240839.BAA23279@usr01.primenet.com> Subject: Re: cvs commit: src/sys/netinet ip_fw.c To: michaelh@cet.co.jp (Michael Hancock) Date: Fri, 24 Apr 1998 08:39:12 +0000 (GMT) Cc: tlambert@primenet.com, wollman@khavrinen.lcs.mit.edu, darrenr@reed.wattle.id.au, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Apr 24, 98 05:00:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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? Are you willing to make the data in the kernel conform to ASN.1? It seems to be a hell of a burden for normal usage. 8-(. I think binding it to the kernel image is sufficient. You can't have loaded a kernel without the image you loaded it from, and you can't be interested in diagnosing a dump unless you are going to boot from that kernel again (why fix an error that can't repeat?). The problem with data-only interfaces is that they either have to be sifficiently abstract that they imply processing overhead that is unnecessary in the common case, or they inmply accessors that are dependent on the instance of the data format, and break between revisions (exactly the problem with "ps" now). The accessor libraries are a general soloution, since they bind to the kernel image, and if you don't have the image, then you can't interpret the dump anyway, and the "ps" against the dump is a higher granularity anyway. You can't buy 75% of something without buying 50% at the same time, so it's a non-problem if you bind to the image. 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