That's what bigphysarea does. It uses a command line
interface to reserve contiguous physical memory that the mm
subsystem is never even told about.
> First we don't know what piece of memory is available for
> removal, on a 64MB machine you want another part of memory
> reserved than on the 2GB one..
It's really for use with devices which have solderspace
limits on their buffer addressing. That is why bigphysarea
grabs its slice as early as possible on boot. bigphysarea is
unable to pick a start address, though. That makes it
useless for devices like Cirrus 5434 on ISA. That is why
e820 comes into the picture.
>
> Second, how can the driver know what piece of memory it can use?
> How can we protect two drivers (sound,grabber?) using the same
> piece of memory twice? etc etc
Excellent point. bigphysarea has no provision in its own
memory management for sharing and locking. It assumes one
driver which owns the space.
The 2.3 resource management makes me think that a physical
framebuffer device can be ginned up without bigphysarea's
limits.
>
> If you revered the guy to the alloc_bootmem() interface I could
> seen some light there, but the mem= interface is not the way to
> go (for the casual user at least!)
>
> Unfortuantly alloc_bootmem does not work for modules...
>
> I see definitly some light for the bigphysarea patch, working
> closely together with alloc_bootmem to get its much needed
> memory...
Like bigphysarea, alloc_bootmem() does its thing in kernel
space. Also contiguous ;-)
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/