Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!vector!egsner!mic!convex!convex.com!tchrist
From: tchrist@convex.com (Tom Christiansen)
Newsgroups: comp.unix.internals
Subject: Interfaces for accessing kernel memory
Message-ID: <109449@convex.convex.com>
Date: 29 Nov 90 00:11:15 GMT
Sender: news@convex.com
Reply-To: tchrist@convex.com (Tom Christiansen)
Organization: Convex Computer Corp, Richardson, TX
Lines: 26

We've all written (or at least seen) programs that make kernel dives
into /dev/mem using an nlist from /vmunix in order to figure out what
some particular kernel variable looks like, or perhaps even to change
it.

Sun has libkvm that helps speed this up a bit, and Convex has a similar
libvm that does the same thing.  Still, this isn't what you really want
for a robust, clean interface.  I'd like a scheme that wouldn't break
just because the version of O/S changed and the structures changed
size, moved around, or whatever.  And I'd really like not to have to
recompile, at the expense of not getting new features just added to a
certain structure.

I've heard that some vendors have a system (or is it library) call for
returning you chunks out of the kernel.  Can anyone tell me how they
seem to work?  I'm talking manpage level details here, not what the
actual source code looks like.

Also, what would you *like* to see in such an interface?  What about
arrays of structures?  Wouldn't it be nice to be able to get the first,
then the next element until null, of the array?

--tom

"With a kernel dive, all things are possible, but it makes it hard
 to face yourself in the mirror the next day."