Jonathan Stone wrote:
> Jason Thorpe writes:
> >Oh..?  Since Charles did all that hacking on the esp driver a bit ago,
> >it's been rock-solid on my sparcs and alphas.  It's sort of my
> >impression that the asc driver is... ill-maintained.
> 
> True, but that's because the asc driver has been rock-solid for some
> time.  I don't know if that was before or after Charles' recent
> hacking of the esp driver.

Does the 'asc' driver actually work properly(*) with the
machine-independent SCSI code?  I see #ifdefs, but as far as I can
tell they're not enabled by anything.  (* == i know you had problems
with the MI SCSI code and large block sizes, but you could have
limited them by cutting MAXBSIZE and MAXPHYS to 8k, at least for
testing...)


I like the 'asc' driver's general structure more than i like the esp
driver's structure -- the 'pseudo-script' approach seems nicer, to me.

However, the 'asc' driver as it currently stands has several serious
drawbacks or potential drawbacks, at least including the following:

	(1) potential instability (due to lack of use/testing) with
	    the MI SCSI code.

	(2) assumption of structure-accessed memory-mapped registers,
	    without encapsulation of accesses.  (the sparc/alpha
	    driver uses macros to read and write controller
	    registers.)

	(3) inadequate (or so it would seem, looking
	    at what the sparc/alpha driver provides) DMA setup
	    capabilities.


I think, at least in my opinion, it comes down to something like:

The design (and name! 8-) of the asc driver is better, but the actual
implementation of the esp driver is better.

To some degree, i'd say that the latter is true because it's been
used more heavily, and on differing types of hardware.


At this point in time, if i had to pick a 53c9x driver to make into
"the MI driver," it'd be esp.c, but (as you'd guess) i'd like to see
some changes before it was made the MI 53c9x driver.


cgd