From owner-freebsd-current Fri Nov 21 11:59:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA06859 for current-outgoing; Fri, 21 Nov 1997 11:59:31 -0800 (PST) (envelope-from owner-freebsd-current) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA06843 for ; Fri, 21 Nov 1997 11:59:25 -0800 (PST) (envelope-from evanc@synapse.net) Received: (qmail 18591 invoked from network); 21 Nov 1997 19:58:20 -0000 Received: from cello.synapse.net (199.84.54.81) by conductor.synapse.net with SMTP; 21 Nov 1997 19:58:20 -0000 Date: Fri, 21 Nov 1997 14:58:19 -0500 (EST) From: Evan Champion To: Jonathan Mini cc: Poul-Henning Kamp , Bruce Evans , mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: Stripping the kernel In-Reply-To: <19971121080934.15793@micron.mini.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 21 Nov 1997, Jonathan Mini wrote: > The problem *I* often have is that there is no /kernel on the filesystem, > which happens in the case of MFS root'd systems all the time. I have been > toying with the idea of writing a device that would use the kernel's saved > symbol table in order to create a pseudo-a.out file which would provide > a symbol table for things like libkvm and friends to read instead of reading > the symbols from a /kernel. (I would like to advance that there is no guarantee > that the kernel image on disk matches the current booted kernel, whereas the > symbols in the kernel are the ones from the image the kernel was loaded from, > and hopefully more reliable) Not really knowing how things go on, excuse me if I seem a little dense in the following :-) It always struct me that reading symbols out of the kernel is a rather backwards way of doing things. Take for example any other application but the kernel... If you wanted to know the value of a variable in that program, you wouldn't open the file up and start looking for symbols... Instead, you'd write an interface that allowed you to access those symbols indirectly. In this case, if nlist() and co. read from a kernel interface instead of reading /kernel directly, you could run a fully stripped kernel, and it wouldn't matter whether the kernel on disk was the same as the loaded kernel, since all that matters is the interface provided by the in-memory image. In a way, that is what you're doing by creating a separate device that programs can read out of, except that the programs are still reading the symbols directly (just through the /dev node instead of /kernel). Evan