>> I am wondering how
>> many people would find a generalised contiguous physical memory allocator
>> useful given that large allocations would probably fail due to wired pages.
>> 
>> Any comments? What functionality do people want?
>
>I actually find the notion of a generalized contiguous physical memory
>allocator (provided by the VM system) to be somewhat objectionable,
>because it's quite likely that it will be badly misused by driver
>writers...
>
>
>e.g. for ISA motherboard DMA, you need contiguous memory regions (in
>the low 16M of RAM), and other systems, e.g. FreeBSD (as i understand
>it; i've not looked at the code) have implemented that via hooks into
>the VM system called by the drivers.
>
>That's bogus, and painful, because there exist machines (e.g. the
>alpha) which use _only_ virtual-mapped DMA windows from the ISA bus
>into main memory, and which place _no_ real memory in that range, etc.

Why not add a "bus_dma_mem_alloc()" to the list of bus* functions?  I
think that such an interface would satisfy most device drivers and the
Alpha implementation can do what every it wants so long as the driver gets
an area that can be DMA'd into.  You could even return a pair of addresses
if that's what some ports may require: one address that the device on the
bus should reference, and the other being the address for use in the
kernel.

I leave the argument about a generic contiguous page allocator in the VM
system for another day, but I would think that the only place it would
be used is for dma applications.

>cgd

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================