ACE, buses, and the future of ultrix

[John Mashey]

In article <816 at cadlab.sublink.ORG> martelli at cadlab.sublink.ORG (Alex Martelli) writes:
>	...
>:for OS software that has yet to be written, why did they need to pick two
>:directions (times two hardware directions gives four?) instead of one?  I
>:may be missing something important, but this aspect of ACE sure looks like
>:one of those "it's a dessert topping; it's a floor polish" skits.
>
>Don't forget they'll support BOTH Dec Turbochannel AND EISA... so, times 
>two again... the bus variation may be the most important of the three, for
>3rd party addon-board manufacturers, and for purchasers of vast numbers of
>machines, who can't really buy machines with different buses if they want
>to be able to minimize spare parts inventory for the addon cards.

This is nonsense.

In the PC world: there are XT busses, AT busses, EISA busses, MCA busses.
Much of this happened sort of by accident, and a lot of software knows too
much about what's there, in gory detail.

ACE assumes that ability to hit different price/performance areas,
and to evolve, requires a sensible scheme for the inclusion of
different busses, (or no bus at all),
which after all, is done by most serious computer systems vendors.
It is absolutely nuts to think that
a bus in widespread use now [EISA, for example] is going to fulfill
everybody's needs in 10 years.

Hence, the ACE compatibility specifications are structured so that one can
have a reasonable shrink-wrapped kernel that doesn't HAVE
to know about the I/O bus choice, but still has enough info to
be able to boot.  This is a lot easier to do when starting from scratch
with the experience of the last 10 years....
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash at mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650