|
| Removal of the brk() and sbrk() interfaces, or actually: stop using the
| break() system call for process heap.
|
| Background:
| 	The "break" interface is a leftover from old times, and as so
| 	it may not interact wery well with newer memory allocators
| 	(i.e. mmap()). In our memory management implementation it also
| 	get the side effect that the allocated memory will span over
| 	a large address space, and for machines with one-level page
| 	tables it may result in lots of wasted space.
|
| Proposal:
| 	Change malloc() et al to use mmap() instead of sbrk().
| 	The phk malloc used by us is changed to use mmap() instead in
| 	a version attached to this mail. (based on the 1.5 release
| 	of malloc.c, but updating it should be trivial).
|
| 	Change brk() and sbrk() to call and use mmap() instead of 
| 	"break". Preferably move them to libcompat, but it may be
| 	reasons for keeping them in libc. An mmap() implementation 
| 	of brk()/sbrk() is attached to this mail.
|
| 	Set sys_obreak() in kernel #ifdef COMPAT_15 and change start
| 	of mmap space calculation. Quite straightforward.
|
| Standards:
| 	Due to Klaus Klein those interfaces are not in any standard anymore.
|
| Side effects:
| 	The compat code that uses "break" must be altered to have their
| 	own version.
|
| 	It is a good time to fix the data size limit checks.

It is necessary to fix the way limits are handled for the data segment
before you can even consider making this change.  Remember that limits
need to work for 32-bit process images, 64-bit process images, *AND* 32-bit
process images running on 64-bit kernels.  This is a difficult problem
to solve considering a 64-bit process can fork+exec a 32-bit process which
can then fork+exec another 64-bit process.  And limits can be changed in
any step of that sequence.  You will definitely get people very angry
if exec-ing a 32-bit process image fails due to the way secions are used
exceeds a 32-bit address space.

Eduardo