From owner-freebsd-hackers Fri Oct 17 19:01:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22383 for hackers-outgoing; Fri, 17 Oct 1997 19:01:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22377 for ; Fri, 17 Oct 1997 19:01:21 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id TAA15379; Fri, 17 Oct 1997 19:01:21 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd015373; Fri Oct 17 19:01:13 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA16463; Fri, 17 Oct 1997 19:01:10 -0700 (MST) From: Terry Lambert Message-Id: <199710180201.TAA16463@usr06.primenet.com> Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) To: darrenr@cyber.com.au (Darren Reed) Date: Sat, 18 Oct 1997 02:01:10 +0000 (GMT) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199710170200.MAA27628@plum.cyber.com.au> from "Darren Reed" at Oct 17, 97 12:00:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's a slow thing. Just a general consencus that lookingin the kernel vm > > for information is notthe way to go in general. > > Granted. I'd correct this to "it's the general consensus that code not associated with the kernel image shouldn't be looking at the kernel data". This isn't *exactly* the same thing... Specifically, the following scenario: 1) The kernel is moved to ELF 2) The kernel loader understands segment attribution 3) Segments with some attributes aren't loaded; segments with other attributes are 4) Segments containing functions for accessing specific are provided in the kernel image 5) The application dlopen()'s the kernel image to obtain the user API segments 6) The application functions independent of structure changes because the "libkvm" and the iteration interfaces are not dependent on seperate code (either libkvm or the user's code) having desynchronized knowledge of kernel structures This basically means that the "ps" and "w" programs must use structure element extraction functions instead of reading and dereferencing the structure elements themselves. This would be pretty easy to accomplish using name/offset descriptors in a not-normally-loaded-by-the-kernel data set in the kernel image. It also happens to nicely solve the "how do I run ps on this system dump" and the "how do I examine this system dump from a -stable user on my -current system" -- both problems that are a pain. The first is a pain because of the need to have the ability to specify multiple synchronized arguments to ps (it's always been annoying). The second is a pain because there is no fix for it at all using the current code, or reasonable anticipated changes to the current code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.