Per Fogelstrom sez:
/*

 * > 
 * > would have thought it would be easy enough for the i386 port to reserve a block
 * > of physical memory at boot time which is then used for a DMA bounce buffer. The
 * > only things which would need changing this way are specific to the port or
 * > drivers. In other words it isn't a job for the core, but for the i386 port
 * > maintainer. Am I missing something?
 * > 
 * No. This is a way to solve it once and for ever regarding the adaptec board.
 * Thus only those with aha1542 boards and ram >16Mb would "suffer" but NetBSD
 * would be usable for many matching this config.

It seems to me that what the x86 PM (and the NetBSD core?) are trying to
achieve -- or at least what the end users want -- is that those with
aha1542 boards and >16Mb core% would NOT suffer inasmuch as bounce
buffers are better than not being able to use the >16MB core at all.

In other words, it would work with a minimum of "suffering" for anyone
with an ISA-based bus-mastering SCSI card and >16MB core.

A very vague pseudo-code might look like (to the inexperienced, anyway):

char	*bounce;	/* global (?) pointer to bounce buffer */
char	*pmalloc();	/* physical memory allocation */
/* 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.
 */

int bounce_init(int ndmadev)
{
    if ((bounce = pmalloc(ndmadev * DMA_BUFSIZ)) == (char *) NULL) {
	return -1;
    }
    return ndmadev * DMA_BUFSIZ;
}

And then, if the bounce buffers have been configured (one per DMA-possible
device (disk/tape)), either load an alternate driver for the DMA devices
which would use the buffers or set a flag.  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.

I don't think I'm too far off base here.

...or Am I Missing Something? [TM]

% please excuse my archaic use of the word "core" instead of RAM here.
  I don't think of "core" as "ferrite core memory", but "core" as in
  "central (or main) memory".  I suspect I'm not the only one... 

 */


				--*greywolf;
--
Timesharing is dead.
Microsoft Windows-NT is going to take over the desktop completely.
UNIX will no longer exist.
And monkeys might fly out of my butt.