RFC: Very large allocations for 2.4.x

[Jeff Garzik]

Like it or not, there is a need to be able to handle very large,
contiguous allocations of physical memory.  Frame grabbers and 3D
drivers both currently use either the "bigphysarea" patch which will
never make it into the kernel, or simply use "mem=XX" to reserve some
RAM for other applications.  Occasional some people come up with other
good uses for big chunks of RAM, which aren't easily implemented in
other ways.

Yes, I am aware that most applications -shouldn't- use this, but I am
hoping to convince the readers here that there is still a need to
support such allocations.  To this end, I propose a simple but flexible
system.  Comments requested.

First, a command line argument ramreserve[1] reserves a region of
physical memory for our use.  This is better than using mem=XX because
it does not depend on installed memory size.

	# LILO: reserve 10 MB of RAM for large allocs
	append="ramreserve=10M"

Then, when the kernel boots, it grabs a 10M region at the end of
available memory using reserve_bootmem, and lists that region in
iomem_resources[2].  From that point, drivers can allocate some or all
of that region using the existing 2.4.x resource allocation system.

'ramreserve' could be later updated to make more than one call to
reserve_bootmem:
	append="ramreserve=10M,2M,4M"
or even reserve specific RAM like
	append="ramreserve=10M@0x00F70000"

The patch to do this would be very small and nonintrusive -- add a
single function to process the ramserver cmd line arg.

If people are agreeable to this, I'll send a patch towards Linus.  Let's
put an end to the hacks like bigphysarea for frame grabbers or using
mem=XX to reserve memory for 3D GLX drivers.

	Jeff

[1] 'reserve' cmd line arg already exists, for reserving MMIO region(s)

[2] Yes I know this is mostly MMIO stuff.  Note the "mostly".  :)

-- 
Jeff Garzik              |
Building 1024            | Free beer tomorrow.
MandrakeSoft, Inc.       |