The allocator shown here  exploits high memory. This document explainshow  a user can  deal   with drivers uses   this  allocator and how  aprogrammer can link in the module.	User's manual	=============One of the most compelling problems with any DMA-capable device is theallocation  of a suitable  memory buffer. The "allocator" module triesto deal with  the problem in  a clean way.  The module is  able to usehigh   memory  (above the  one   used in  normal   operation)  for DMAallocation.To prevent  the  kernel for using   high memory,  so  that it  remainsavailable for  DMA, you should  pass a  command  line argument to  thekernel.  Command line arguments  can be passed to  Lilo, to Loadlin orto whichever loader  you are using  (unless it's very poor in design).For Lilo, either use  "append=" in  /etc/lilo.conf or add  commandlinearguments to the  interactive prompt. For  example, I have a 32MB  boxand reserve two megs for DMA:In lilo.conf:	image = /zImage	label = linux	append = "mem=30M"Or, interactively:	LILO: linux mem=30MOnce  the kernel is booted  with the  right command-line argument, anydriver  linked   with  the  allocator   module  will  be able   to getDMA-capable memory without  much  trouble (unless the  various driversneed more memory than available).The module implements an alloc/free  mechanism,  so that it can  servemultiple drivers  at the  same time. Note  however that  the allocatoruses all of  high memory and assumes to  be the only piece of softwareusing such memory.	Programmer's manual	===================The allocator,  as  released, is designed  to  be linked  to  a devicedriver.  In this  case, the driver  must call allocator_init()  beforeusing   the  allocator   and  must  call   allocator_cleanup()  beforeunloading.  This is  usually  done   from within  init_module()    andcleanup_module(). If the allocator is linked to  a driver, it won't bepossible for several drivers to allocate high DMA memory, as explainedabove.It is possible, on the other hand, to compile the module as a standalonemodule, so that several modules can rely on the allocator for they DMAbuffers. To compile the allocator as a standalone module, do thefollowing in this directory (or provide a suitable Makefile, or editthe source code):	make allocator.o CC="gcc -Dallocator_init=init_module -Dallocator_cleanup=cleanup_module -include /usr/include/linux/module.h"The previous commandline  tells   to include <linux/module.h>  in  thefirst place,  and to rename the init  and cleanup function to the onesneeded for  module loading and  unloading.  Drivers using a standaloneallocator won't need to call allocator_init() nor allocator_cleanup().The allocator exports the following functions (declared in allocator.h):   unsigned long allocator_allocate_dma (unsigned long kilobytes,					 int priority);	This function returns a physical address, over high_memory,	which corresponds to an area of at least "kilobytes" kilobytes.	The area will be owned by the module calling the function.	The returned address can be passed to device boards, to instruct	their DMA controllers, via phys_to_bus(). The address can be used	by C code after vremap()/ioremap(). The "priority" argument should	be GFP_KERNEL or GFP_ATOMIC, according to the context of the	caller; it is used to call kmalloc(), as the allocator must keep	track of any region it gives away. In case of error the function	returns 0, and the caller is expected to issue a -ENOMEM error.   void allocator_free_dma (unsigned long address);	This function is the reverse of the previous one. If a driver	doesn't free the DMA memory it allocated, the allocator will	consider such memory as busy. Note, however, that	allocator_cleanup() calls kfree() on every region it reclaimed,	so that a driver with the allocator linked in can avoid calling	allocator_free_dma() at unload time.