> /* DMA_BUFSIZ would be (is?) defined to be some arbitrary amount of memory
>  * suitable for most DMA transfers; 126 blocks seems to be the upper
>  * limit for many SCSI devices.  At least Sun format and the restrictions
>  * on record lengths on non-streaming devices would have one think so.
>  */

I suspect this is a VAX legacy.  Unibus devices took a byte transfer
count for DMA.  This was always (in my experience) a 16-bit unsigned
value.  The kernel limited it to 63K rather than 64K-1 because, as I
recall (probably from comments in the kernel), it wanted to catch
mistakenly passing a small negative number as the count.

The 63K limit has, I suspect, been perpetuated from there, copied from
kernel to kernel.  Even today, there are some devices that have only 16
bits for the transfer count.  The sc SCSI interface I'm working on a
driver for for NetBSD/sun3 is an example (granted, it's pretty much
legacy hardware in its own right at present); given a 64K hard limit,
catching small negative counts still makes a 63K limit seem reasonable.

> I think loading the alternate drivers would be preferable since if
> you have to check a flag every time you attempt a DMAX, you're going
> to get some performance problems.

Taking the DMA-completion interrupt is far, far more expensive than
making a single test of a flag.  At least on any architecture I've ever
looked at, which means VAX, 68k, and SPARC off the top of my head.  And
if you're polling for DMA completion, you obviously don't care about
the performance hit of testing a single flag bit.  Not unless you've
got one king hell of a DMA engine, with memory speeds to match.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu