[SunRescue] Hardware reference re-structuring ideas.

Gregory Leblanc gleblanc at cu-portland.edu
Wed Jan 5 14:59:34 CST 2000


Chris Petersen wrote:
> 
> [snip!]
> 
[...]
> 
> 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.

So you're saying don't lump servers and workstations together, right? 
Just want to make sure I can still read.

> 
> >
> > > 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

I'm thinking that it would be worth breaking down the individual bus
sections into categories for each type of card (lump SCSI cards
together, etc).

> 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 looks pretty good, with a quick read-over.  I'll try to take some
time and look at everybody responses in more detail this evening.

> 
> 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).

This document WILL be written in DocBook SGML, for portability, and
maintainabliity.  I know for sure that I can create HTML, PS, plain
text, and a couple of other formats from this, so it seems like the best
solution for this problem.  DocBook also allows you to automagically
create indexes and Tables of Contents.  Very cool stuff...

> 
> 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.

You mean the Field Engineers Handbook?  I've got one that I use as
reference, but the oldest machines in it are I think Sun4m.  The content
that I can put in there is a TINY bit about the SS20, and the info in
the version that I downloaded from Mr. Bills page.  This means that I'm
relying on you guys to help me flesh out the newer data.

> 
> 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.

I'll try to do most of my brainstorming on-list, to make sure I don't do
anything really stupid, and what we get the best document possible. 
Thanks again, and I hope to hear more from the rest of you,
	Greg






More information about the rescue mailing list