Date: Fri, 21 Nov 1997 14:58:19 -0500 (EST) From: Evan Champion <evanc@synapse.net> To: Jonathan Mini <j_mini@efn.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Bruce Evans <bde@zeta.org.au>, mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: Stripping the kernel Message-ID: <Pine.BSF.3.96.971121145018.470D-100000@cello.synapse.net> In-Reply-To: <19971121080934.15793@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971121145018.470D-100000>