Access to kmem - System namelist - 'ps' etc

[Dick Dunn]

>...
> >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?