3723edm (01/02/83)
A while back, a question was raised about how to find out what's in kmem, e.g. how to you locate the process table, what's there once you find it, and whatever other goodies may be there. Subsequent articles discussed why reading kmem was a bad idea, and suggested improved interfaces to obtain the information in kmem. This discussion is all well and good, but I am still hoping somebody will provide the information originally requested. In addition, I would like some suggestions on what users who have permission to both read and *write* kmem and mem can do with this ability. There are apparently several systems where reading and *writing* kmem and mem are allowed, and I would think this capability could be put to various interesting uses. I have read enough about why these programs should be written using better interfaces, so there's no point in flaming about why it's so lousy to access kmem directly--that is the only interface provided. Eli Mantel, houxq!3723edm
johnl (01/03/83)
#R:houxq:-23200:ima:9200001:000:1248 ima!johnl Jan 2 19:03:00 1983 If you really want to look at kmem (and your system allows you to do so) then the usual procedure is: -- use nlist() to extract symbols from /unix, to find out where in memory stuff is. Note that this can fail if the system was booted from somewhere else. -- The system data structures are mostly defined by include files in /usr/include/sys. There is no substitute for reading kernel code to find out what stuff actually means. If you have no sources, sorry, you lose. -- Open /dev/kmem, seek to the right place, and copy stuff in. -- Do what you will. Look at the source code for the "ps" command for an extended example of this sort of thing. The convoluted and ugly code you find there is typical of what happens when you deal with kmem. The Berklix "renice" command is an example of patching kmem; it lowers a process' priority. The most legitimate uses of kmem reading appear to be programs like "ps" and "iostat." Kmem patching seems useful only for hacks like renice and somewhat for debugging kernel code. It is my strong impression that system managers that allow significant use of kmem patching usually live to regret it. John Levine, decvax!yale-co!jrl, ucbvax!cbosgd!ima!johnl, Levine@YALE (arpa).