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.

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?

-Jonathan