From owner-freebsd-current Sat Nov 22 12:17:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23547 for current-outgoing; Sat, 22 Nov 1997 12:17:08 -0800 (PST) (envelope-from owner-freebsd-current) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA23542 for ; Sat, 22 Nov 1997 12:17:05 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id MAA07448; Sat, 22 Nov 1997 12:16:51 -0800 (PST) Message-ID: <19971122121650.07602@micron.mini.net> Date: Sat, 22 Nov 1997 12:16:50 -0800 From: Jonathan Mini To: Jim Shankland Cc: j_mini@efn.org, current@freebsd.org Subject: Re: Stripping the kernel Reply-To: Jonathan Mini References: <199711220025.QAA05276@biggusdiskus.flyingfox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199711220025.QAA05276@biggusdiskus.flyingfox.com>; from Jim Shankland on Fri, Nov 21, 1997 at 04:25:55PM -0800 X-files: The Truth is Out There Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jim Shankland stands accused of saying: > Jonathan Mini writes: > > > Evan, you are absolutely right. It is Bad and Evil to read things out > > of the kernel memory. I have hated it from the start. However, look at > > the uses of the kernel tompling, and come up with an effective > > efficient way to do the same things, and I will even write it for > > you. :) > > Tompling? Ooops typo : trompling. (tromp tromp tromp... picture rainboots and puddles) > There are plenty of alternatives, all in use today: > > ioctl (think SIOCGIFCONF); > sysctl > /proc file system > special sockets (think PF_ROUTE); > good old poking through the kernel nlist. > > Take your pick. Or invent yet more. Question to think about: > how many of the above can be used on kernel dump files? I have a borune script that does some of ps's features via procfs, and it is _really_ slow. :( Also, it misses much of the features I needed, so I never did use it. The problem is processes that open /kernel in order to find symbol locations, then open /dev/kmem to read the contents of those symbols. This breaks if there is no kernel image available anywhere once the system boots. (as happens with MFS root systems) > > Jim Shankland > Flying Fox Computer Systems, Inc. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."