Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!cornell!uw-beaver!tektronix!teklds!zeus!bobr
From: bobr@zeus.UUCP
Newsgroups: comp.sys.apollo
Subject: Re: /dev/kmem ...
Message-ID: <1894@zeus.TEK.COM>
Date: Fri, 19-Jun-87 16:23:10 EDT
Article-I.D.: zeus.1894
Posted: Fri Jun 19 16:23:10 1987
Date-Received: Sat, 20-Jun-87 19:14:11 EDT
References: <8706181935.AA01574@fleetwood.cc.umich.edu>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 24

In article <8706181935.AA01574@fleetwood.cc.umich.edu> paul@FLEETWOOD.CC.UMICH.EDU ('da Kingfish) writes:

	>"I am no UNIX guru and so would like to know what's wrong in
	>using /dev/kmem"

    I think we (those of us who don't like using /dev/kmem even if we have
    one on the system) say something like "procedural interfaces are nicer
    than having to know about data structures."

It's fine to say that procedural interfaces are safer and provide a more
insular wall between a changing kernel and the applications which it
supports -- as long as those procedural interfaces are provided to the user.  

To my knowledge, albeit limited on this subject, there is no documentation
from Apollo in the procedural interfaces to support such a program as ps(1).
I happen to prefer the output of sps, a public domain version of ps, but I
have no possibility of porting it without knowing this interface.

I agree that /dev/kmem is a hackers delight but a system developer's
nightmare.  However, having access to /dev/kmem (and adequate documentation
on the system tables of interest) provides at least some means of obtaining
the desired information, which is better than no means at all.
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK