Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!uw-beaver!tektronix!teklds!zeus!bobr
From: bobr@zeus.TEK.COM (Robert Reed)
Newsgroups: comp.sys.apollo
Subject: Re: procedural interfaces
Message-ID: <1918@zeus.TEK.COM>
Date: Thu, 25-Jun-87 17:06:52 EDT
Article-I.D.: zeus.1918
Posted: Thu Jun 25 17:06:52 1987
Date-Received: Sat, 27-Jun-87 05:00:42 EDT
References: <8706242145.AA09122@EDDIE.MIT.EDU>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 48

In article <8706242145.AA09122@EDDIE.MIT.EDU> krowitz@mit-kermit.UUCP (David Krowitz) writes:

    The reason that the procedural interfaces that people have been
    complaining about are missing from the system is that not enough people
    have written UCRs demanding that Apollo release the system calls.

Are you certain of this?  I've gotten several private messages from persons
at Apollo (probably not policy, but closer than speculation) to the effect
that they haven't released the procedural interfaces under discussion
because they don't want to be forced to support those interfaces in future
versions.  This sounds very much like the motivation for not having
/dev/kmem--so there we are, no closer to a solution.

    The same hold true for BSD 4.2, if enough people complained to Berkley
    they might do something about the fact that many programs which do
    useful things must go mucking around in /dev/kmem. 

Pleasant dream.  The reality of course is if it ain't broke, don't fix it.
What motivation does Berkeley, short of another DARPA contract, have to
provide equivalent function in a procedural interface?  My guess is that
such complaints directed to Berkeley will fall on deaf ears.

    I have some procedures which do the things that A. Petrilli complains
    about, but they do so by invoking LCNODE, LUSR, NETSTAT and the like and
    parsing the output. This suffers from the same problem as /dev/kmem --
    mainly anytime the format of the output of these programs changes (or
    the internal structure of /dev/kmem is updated), the programs which rely
    upon this method break badly! 

This of course, misses the point.  What you have demonstrated is that in the
absence of support, for procedural interfaces or otherwise, that desperate
measures will be taken to derive such information.  You yourself have
justified measures such as /dev/kmem, because by resorting to them you were
able to get the job done, albeit by means of a structure which is somewhat
tenuous.

    A 'clean' system call is always preferable to messing around in a data
    structure -- it gives the systems programmer a stable interface to the
    OS while at the same time allowing the OS/kernal programmers to make
    changes that aren't going to come back to haunt them forevermore.

I agree, however, as a pragmatic matter, devices such as kmem are a cheap
means to provide such function.  All the sellers need provide is a simple
document describing the internal tables and place the onus on users to
upgrade their tools appropriately.  As far as I can tell, Apollo has
provided neither, nor do they plan to in the near future.
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK