Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!gatech!cuae2!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.arch Subject: Re: Missionary Position .vs. 69 Message-ID: <5100112@ccvaxa> Date: Thu, 17-Jul-86 10:38:00 EDT Article-I.D.: ccvaxa.5100112 Posted: Thu Jul 17 10:38:00 1986 Date-Received: Sat, 19-Jul-86 02:11:05 EDT References: <2900019@ztivax> Lines: 30 Nf-ID: #R:ztivax:2900019:ccvaxa:5100112:000:1636 Nf-From: ccvaxa.UUCP!aglew Jul 17 09:38:00 1986 >There is no such thing as "bottom up" or "top down" design -- there is good >design and there is bad design, and a good designer will think about his >problem from an overall standpoint (top down) and then based on this, create >the primitives that are needed (bottom up). Yes and no. For a particular program top down design followed by bottom up implementation of the primitives that are needed may be good - but operating systems aren't programs, they're toolboxes. Same thing for computer architectures. The problem lies with people who create (only) the primitives that are needed, but no more. What this leads to in operating systems is situations where there are three types of multiprocessor locking operations, for example, but the original implementor only needed two, so he didn't implement the third. When the need for the third type of lock arises nobody can understand the original code (which is another problem in itself) so a slightly different variety of locking mechanism is created, but this time the second kind is left out. So you end up with four or five or six varieties of lock, all incompatible, logically redundant, that can't be mixed. Is this good? Top down design, right. Discover what primitives you need, right. Then try to make a system out of the primitives. Imagine what type of top down design can use the primitives that you don't need right now. Frequently you'll find that you can use them. Repeat until things your design stops changing so quickly. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms