Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!nsc!chuqui
From: chuqui@nsc.UUCP (Cheshire Chuqui)
Newsgroups: net.unix-wizards
Subject: Access to kmem - System namelist - 'ps' etc
Message-ID: <1973@nsc.UUCP>
Date: Wed, 5-Dec-84 02:53:43 EST
Article-I.D.: nsc.1973
Posted: Wed Dec  5 02:53:43 1984
Date-Received: Thu, 6-Dec-84 03:50:56 EST
Organization: Plaid Heaven
Lines: 33

References <161@dido.UUCP> <1974@vax4.fluke.UUCP>
Reply-To: chuqui@nsc.UUCP (Cheshire Chuqui)
Distribution: 
Organization: Plaid Heaven
Keywords:
Summary:

 
>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. I have a distinct aversion for programs
that run exceptionally slow because of a seldom-used special case-- better
to make two versions; one fast for normal use and one for the special case.

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.

chuq
-- 
From the center of a Plaid pentagram:		Chuq Von Rospach
{cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui  nsc!chuqui@decwrl.ARPA

  ~But you know, monsieur, that as long as she wears the claw of the dragon
  upon her breast you can do nothing-- her soul belongs to me!~