> From: Michael Sokolov <sokolov@alpha.CES.CWRU.Edu>
> 
> > From: Allison J Parent
> >
> > Smaller and specific is always
> > better than larger more general.
> 
>    So you like duplicating a huge source file to change one line, don't
> you?

	It could be she prefers to have the option to configure the
	kernel for a faster, cleaner codepath, or maybe just the basic
	supportability of having a machine independant chip driver, with
	specific attachment code for each of the _different_ environments.

	Incidently this may hold an answer to why the later VS3100 SCSI
	driver would not be immediately viable on the VS2000 - the 3100
	had a larger 128KB buffer which quite possibly should be accessed
	in a different fashion, plus the DMA setup is obviously different.
	(However I am not interested in continuting that thread)

> > From: Bertram Barth
>
> > BTW: From the docs I have it seems that HDC9224 is at the same address
> >      for all VAXen, same holds for NCR-1 and NCR-2, for SCSI-DMA and for
> >      interrupt-registers. Thus at least some parts of the existing
> >      drivers should be usable for other models 3100...
>    
>    Sure they are! If the addresses were different, Ultrix would be broken
> miserably.
>    
	If there was a compelling hardware reason why the address _had_
	to be different on a later machine then Ultrix could quite easily
	have coped - it would just have had to try an additional match.

> > In "hdcmatch()" it would be fairly easy (IMHO) to add support for HDC9224
> > on other VAXen [...]
>    
>    It surely is! The way the hdc driver checks for KA410 and refuses to
> load if it's something else smells like (heaven forbid!) artificial
> blocking... :-)
>    
	Or convervative programming from someone with limited access to
	different hardware, and who is more than willing to help anyone
	else interested in working on the driver...

>    Some personal comments. Your description mostly coincides with what I
> have discovered by studying your code, and both lead to the same

	How nice... 

> conclusion: the problems that these drivers are plagued by are a result of
> the extremely quick-and-dirty way in which they have been written. Trial-
> and-error and "I have no idea why this works" never lead to robust
> software. To make sure that my work goes in the right direction, I won't
> even start writing any code until I get a complete and perfect
> understanding of the hardware involved. First I'll read all of the
> available manuals, and then I'll fill in the missing pieces by reverse-
> engineering Ultrix.
>    
	Please do. Could I further suggest you intensively concentrate
	on the above, excluding all further port-vax emails until you
	have finished.

>    But apparently you had at least some technical info. When you were
> writing the hdc driver and the MD portion of the ncr driver, you had to
> have the info on them. Had you got it all from the MV2000/VS2000 technical
> manual? Did you use the datasheets from SMC and NCR?

	You amaze me - most of us remain significantly impressed by what
	Bertram managed to achieve on so little documentation, while
	you dismiss it above with an arrogance that borders on contempt,
	and then have the gall to ask him for copies of his documentation.

	You also insult Alison, one of the few other people still talking
	to you on this list.

	_If_ you are a superlative programmer and can achieve all your
	stated goals, then I would be able to respect you for that (even
	if I consider the goals misplaced), but in no other way have you
	shown yourself to be worthy of respect.

	I suggest you setup your own listserver for your OS and related
	matters (NetBSD uses Majordomo from www.greatcircle.com), send a
	_single_ message to this list informing those who wish to
	subscribe of your list's address, and then refrain from posting to
	this list again. You would be doing us all a great service.

	Thankyou.

		David/abs