[SunRescue] Hardware reference re-structuring ideas.

Michael C. Vergallen mvergall at double-barrel.be
Wed Jan 5 20:26:03 CST 2000


I would also suggest having the document in a PDF format ( with all the
indexes and cross references in the way Chris describes) this would make 
the document easy to use as a off-line document. Also a section on the
more exotic cards sush as the 'DGM&S V35 cards' and so on would be good 
for reference...plus someone should try and obtain more hardware
documentation for the more offbeat cards..before they are lost for ever.
Also what would be a nice aldo a bit of a task to produce is a archive of
all the sun os software that was produced. e.i sunos 3.0, 3.5 etc. or
references to it..for the serious collector of sun equipment so that ones
a sun machine becomes decommissioned for the last time it could be
restored in its original form just for historical reasons...that's why I
kept all the old 105 MB and 200 MB hard discs. To one day reinstall the
systems in their original glory. 

Michael
---
Michael C. Vergallen A.k.A. Mad Mike, 
Sportstraat 28			http://www.double-barrel.be/mvergall/
B 9000 Gent			ftp://ftp.double-barrel.be/pub/linux/
Belgium				tel : 32-9-2227764 Fax : 32-9-2224976
			
On Wed, 5 Jan 2000, Chris Petersen wrote:

> 
> [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)
> 
> _______________________________________________
> Rescue maillist  -  Rescue at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/rescue
> 







More information about the rescue mailing list