🚀 go-pugleaf

>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