krowitz@mit-kermit.UUCP (David Krowitz) (06/25/87)
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. 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. 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! 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.
In short, if you want it and it ain't there, write the UCR! If you can't figure out
what all of the fields are for, then leave 'em blank -- that's what I do and Apollo
hasn't complained about it yet.
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)bobr@zeus.TEK.COM (Robert Reed) (06/26/87)
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.TEKdfm@JASPER.PALLADIAN.COM (Don Morrison) (06/26/87)
Date: 25 Jun 87 21:06:52 GMT
From: tektronix!teklds!zeus!bobr@ucbvax.Berkeley.EDU (Robert Reed)
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 story I've been getting from folks at Apollo lately is that they've finally biten the bullet and accepted that
they'll have to release more formerly internal-only system calls, and have plans for releasing various ones with
upcoming OS releases. If we don't tell them just what we want them to release, they'll continue to try to guess what
we want; far better that we try to tell Apollo specificially what functionality we want them to provide public
interfaces for. If there's information you feel a need to be able to get, from /dev/kmem or elsewhere, and can't do
it on an Apollo, send them a list of specifics; they're actually reasonable people who know they'll sell more boxes
to happy customers than angry ones.krowitz@mit-kermit.UUCP (David Krowitz) (06/29/87)
No, sorry, YOU missed MY point! (as usual).
Of course Apollo (or Berkley, or anyone else for that matter) wants to
support as little software as they have to. The point I was making was
that if enough users get together and ask for the same feature time and
again, then the manufacturer (Apollo in this instance) will feel some
pressure to provide it. If everyone just sits on their ass and grumbles
to themselves and never get around to writing UCRs (or sending mail to
Sun, or whatever) then NOTHING WILL EVER CHANGE, and we will be forced
to muck around with /dev/kmem (or invoke LCNODE, or someother horrible
kludge which will break just as soon as someone changes the kernal).
The problem with a feature like /dev/kmem is that by publishing the
structures on the internal tables of the kernal you have created a
program interface which must be supported just like any other system
library *and* you have, at the same time, made an irrevocable decision
about how the kernal is going to look in the future. If a feature is
needed in the OS, the thing to do is to get together 10 or 20 people
from across the country (easy enough to do with email) and have a UCR writing
party, not to demand that the entire kernal be rewritten to look like
an operating system that was cast in stone 10 years ago.
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)gnu@hoptoad.uucp (John Gilmore) (07/01/87)
krowitz@mit-kermit.UUCP (David Krowitz) wrote: > If a feature is > needed in the OS, the thing to do is to get together 10 or 20 people > from across the country (easy enough to do with email) and have a UCR writing > party... Hmm, in the Unix community we have a code writing party instead, and then post the change to the net. In their next release Berkeley picks it up. Two years later Sun and DEC pick it up. Five years later AT&T picks it up but changes its name.
freedman@calgary.UUCP (Dan Freedman) (07/01/87)
In article <8706291746.AA09491@EDDIE.MIT.EDU>, krowitz@mit-kermit.UUCP (David Krowitz) writes: > Of course Apollo (or Berkley, or anyone else for that matter) wants to > support as little software as they have to. The point I was making was > that if enough users get together and ask for the same feature time and > again, then the manufacturer (Apollo in this instance) will feel some > pressure to provide it. If everyone just sits on their ass and grumbles > to themselves and never get around to writing UCRs (or sending mail to > Sun, or whatever) then NOTHING WILL EVER CHANGE, and we will be forced > to muck around with /dev/kmem (or invoke LCNODE, or someother horrible > kludge which will break just as soon as someone changes the kernal). Of course, the buyer has one rather strong option that doesn't require him to write any UCRs, and that is to buy elsewhere. While customer feedback is very important in determining future improvements to a product, a customer is going to feel far better about spending money on a product where the vendor is innovative enough to improve the product without being bullied into it by its customers. (Note that I'm speaking generally here, and not specifically about Apollo). A vendor should be able to look introspectively at its products in order to improve them to gain new customers (who, since they are not yet customers, won't be sending in UCRs!) Thus, I disagree with your statement that nothing will ever change without UCRs. At the very least, if a product does not change, if it stagnates, then the vendors competitors will surely take advantage of the fact, and the products market share will drop. IBM is quite possibly an exception to all of this. 9~> Dan Freedman
weber_w@apollo.uucp (Walt Weber) (07/02/87)
In article <2349@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >krowitz@mit-kermit.UUCP (David Krowitz) wrote: >> If a feature is >> needed in the OS, the thing to do is to get together 10 or 20 people >> from across the country (easy enough to do with email) and have a UCR writing >> party... > >Hmm, in the Unix community we have a code writing party instead, and then >post the change to the net. In their next release Berkeley picks it up. >Two years later Sun and DEC pick it up. Five years later AT&T picks it up >but changes its name. John -- 1) does this mean that one cannot be a member of your "Unix community" without a source license? 2) if your approach met the general-case needs, would there be a market for the services provided by, say, Mt. XINU? It looks to me like your approach leaves out the collection of binary-only sites who do not have an interest in kernel thwacking, but would like to have additional features added to their systems. -- Walt Weber PHONE: (617) 256-6600 x7004 Apollo Computer GENIE: W.WEBER Chelmsford, People's Republic of Massachusetts