Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!hao!cires!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - 'ps' etc Message-ID: <970@opus.UUCP> Date: Sat, 8-Dec-84 01:13:48 EST Article-I.D.: opus.970 Posted: Sat Dec 8 01:13:48 1984 Date-Received: Mon, 10-Dec-84 02:43:16 EST Organization: NBI,Inc, Boulder CO Lines: 40 >... > >However, it does complicate the case of ps, etc., reading core dumps. > >No matter what change you propose to /dev/kmem, it is bound to break > >ps, pstat, etc., access to crash dumps. I really like being able to > >use ps on crashes, but I also dislike the speed penalty you pay for > >runtime-access. There must be a better (or at least faster) way! > > > >As I see it, ther is no easy solution (or free lunch for that matter). > > Actually, there is. If there were decent crash analysis tools, we wouldn't > need to hack out the run-time tools to do crash analysis for us and take > the associated run-time penalties... But there's a big win in having the same tool used for a look at a running system and at a crash dump--you're MUCH more likely to get the same answer. If you see something odd in a ps or a pstat of a sick system, you might like to be able to euthanatize it and find the same thing in the corpse. Moreover, there are probably reasonable ways to streamline or eliminate the digging through the namelist without breaking the usefulness as a debugging tool. > I've looked at converting kmem reads to system calls-- in my copious free > time one of these days I'd like to implement it. Kmem, to put it simply, > scares me. Agree wholeheartedly. I've always been uneasy about it; I've been absolutely paranoid since a moderately clever programmer showed me the program he wrote in about a day to spy on clists and watch any terminal he chose. (Admittedly it missed characters, but...) I'd probably even give up the ability to "adb -w /vmunix /dev/kmem" to indulge my paranoia a bit. Why not retain the current model but put some finer-grained protection in? That is, let the kernel be selective about what areas of memory it will read for a process. This is perhaps ratty, but you don't end up trying to reorganize a system call when you discover that ps, pstat, or some new tool you've designed needs access to a data structure you didn't plan on at first. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Are you making this up as you go along?