[SunRescue] Hardware reference re-structuring ideas.

Chris Petersen havoc at apk.net
Wed Jan 5 14:21:39 CST 2000


[snip!]

> 
> I think it breaks things up a little too much that would be better kept
> together. I quite like the current date-ordered list, as it also gives
> an idea of which machines were contemporary with a given beast. I agree
> that it is perhaps becoming a little unwieldy in the case of the SPARCs,
> but I think that unless a division is intuitively obvious to a new
> reader it shouldn't be made. I like the way that looking at the model
> number on the machine is all you need to know which section it's in
> (if there's no number, it's one of the first two...) If Ultras are added,
> they could go in their own section, but I like having all the other
> SPARCs together.
> 
> Otherwise, we have the case that SPARCstation IPX is in the sun4c section,
> while SPARCstation LX is in the sun4m section; SPARCstation 2 is in the
> sun4c section while SPARCstation 4 is sun4m; and Sun 4/400 is in the sun4
> section but Sun 4/600 is in the sun4m section. Given the superficial
> similarity in model numbers, this could confuse a new reader even further
> than the current big section.
> 
> Kernel architecture is something of an obscure thing to a new reader. ;)

However, the date-influenced information is mostly of a historical interest,
and not as indicative.  I think the best approach for organization of the
workstations & servers would either be purely alphabetical (allowing 
for quick reference), or broken down by kernel architecture in terms of
relative chronological order (i.e. Sun3 followed by Sun3x, Sun4 followed by
Sun4c and Sun4m).

I definetely think there needs to be a seperate section as there is now for
addressing the workstations and servers as a "type" of hardware, as opposed
to lumping the whole thing together.  Say, a section with the basics on the
lineup by architecture, followed by sections in detail on each style of
machine, cross-linked to appendices based on host-bus architecture.

> 
> > Idea number 2 would be to break the machines and board down into
> > different interfaces.  There could be an SBUS section, a VME section,
> > and a PCI section.  This idea sounds a lot more limiting at the top, but
> > under each of those sections, I could have a sub-section for each arch.
> > The third idea would be to modify the existing layout to allow for
> > easier management.  I'd want to combine/re-break out sections 3 and 4,
> > perhaps into one section for each interface, more or less.
> 
> Structuring expansion boards by host bus architecture would be a very
> good idea, IMHO. I say host bus architecture so that, say a VME->Multibus
> bridge would go in the VME section rather than the Multibus section.
> This would correspond to combining 3 and 4 and then splitting by bus.

Agreed.

> 
> This works because boards only have one host bus on them. Trying to
> structure CPUs by bus won't work as well because some have more than
> one bus (for example, the 4/600 as mentioned by James Lockwood).

Definetely.  What I think you're looking at, at least IMHO, would be
something like this:

A. Introduction (some rough history of Sun, purpose of FAQ)
B. Sun Hardware Specifications (Basics, bus, speed, memory type)
	  1. Sun1
	  2. Sun2
	  3. Sun3
	  4. Sun3x
	  x. ...
	x+1. Chronological Reference chart
C. Architecture, Hardware Specifics
	  1. Sun1 Architecture Notes
		a) SUN 1 Hardware Notes/Errata
		x) ...
	  x. ...
	  x. Sun4m Architecture Notes (maybe list of modules, etc)
		a) SPARCStation 5 Hardware Notes/Errata
		b) SPARCStation 10 Hardware Notes/Errata
		c) SPARCStation 20 Hardware Notes/Errata
		x) ...
D. System Options, Processors, etc. by Bus (or in the case of non-bus specific,
   by function)
	  1. MultiBUS
	  2. VME
	  3. Sbus
	  x. ...
	  x. Keyboards & Mice
E. Part Number reference list (wherever possible, cross-linked back to
component details)
F. Indices
	  1. By Alphabetical for machine type
	  2. By Bus?
	  3. By Date

This is just a rough idea of a layout, but whenever I've kicked around the
idea of offering to update the hardware reference, this is what I've thought
about.  I tried to flesh out a few sections to give you an idea, although I
must say I'm not entirely satisfied with the titles I used. 

It would be nice to take advantage of HTML for this, but whatever the end
result is it should also be conveniently be usable in pure text format.  By
that, I mean the links should not merely be hyperlinks on particular words
or references as much as there should be some sort of orderly reference
method that works both ways (not footnotes, but something that indicates
both visually and via hyperlink where you can get more information on the
subject).

Oh, and if you want a good example of how not to do it, take a look at the
Sun FE sometime, if you have access.  It seems like I have to bounce all
over the place in it to find what I'm after.

And if you need any help in this endeavor, Greg, give me a holler.  Me and a
couple of friends would be more than happy to help somehow, even if it's
just nailing down an organizational method.

Chris

-- 
Chris Petersen
Systems Engineer
Unigraphics Solutions Inc.		Industry Services, Mid-America Region
Email: havoc at apk.net (Personal)       petersen at ugsolutions.com (Professional)






More information about the rescue mailing list