["tech-userspace@netbsd.org" removed, since such a list doesn't exist.]

On Tue, 26 Feb 2002, Wolfgang Solfrank wrote:

: > Removal of the brk() and sbrk() interfaces, or actually: stop using the
: > break() system call for process heap.
:
: What about programs that dump themselves for later restart (like emacs,
: TeX etc.)?

Other than the fact that this is a gross, machine-dependent, abuse of
virtual address space that makes linking with shared objects hairy at best?
(IMNSHO, all such programs are just plain bogus, and should instead save
their binary state in a way that can be read() or mmap()ed back into
memory.  There's no excuse for emacs to keep using its undump scheme.  8-)

: Those programs dump the memory from the start of the data section
: up to the break value as the data section of the new executable.
: How would this be handled in the new world?

Well, malloc(3) could be left to call sbrk(), and then sbrk() be changed to
use mmap() in libc.  With this scheme, brk() could still return a usable
value.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/