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!~