Date: Sat, 18 Oct 1997 02:01:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: darrenr@cyber.com.au (Darren Reed) Cc: julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) Message-ID: <199710180201.TAA16463@usr06.primenet.com> In-Reply-To: <199710170200.MAA27628@plum.cyber.com.au> from "Darren Reed" at Oct 17, 97 12:00:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710180201.TAA16463>