To: Chris G. Demetriou <cgd@CS.cmu.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/20/1997 18:02:14
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
> (3) inadequate (or so it would seem, looking
> at what the sparc/alpha driver provides) DMA setup
All fair comments.
The Pica port seems to address (1) -- quite thoroughly, if the OpenBSD
ARC port still uses an asc-derived driver.
I don't have an answer for (2).
The DMA setup capabilities are[ addressed by the never-commited
rewrite in my own tree, which made the DMA start/stop code be a
callback to bus-dependent, attachment-specific functions. This was
*meant* to fit into a future <bus.h>, but that seems to be slow in
arriving. Is a call through a function pointer more or less
attractive than how the esp driver handles this?
I'd sooner see any MI asc driver be pseudo-script-based, for the same
reasons Chris likes that design. The `esp' name is a Sparc-ism that's
painful and counter-intuitive for machines with PROMs and/or vendor OS
code cthat refer to an "asc" -- no less so than "asc" would be on
Sparcs, for the same reasons. Perhaps the right fix is allowing an
attachment-specific override of the driver name visible to users?