I have been working on reconfiguring my kernel to allow larger data
segments than the default 32MB.  This can be done by changing the
value of MAXDSIZ (see <machine/vmparam.h>).  The value of USRSTACK,
which defines the address of the top of the user stack limits the
value of MAXDSIZ in the sense that MAXDSIZ should be small enough to
accomodate a hole in the address space between the top of the largest
data segment (top of text + MAXDSIZ) and the bottom of the largest
stack segment (USRSTACK - MAXSSIZ) of sufficient size.  This hole is
used to map in ld.so and any shared libraries as well as other mmap'ed
files.  I found that if the hole was too small or non-existent,
dynamically linked programs will fail with `Cannot map ld.so' and the
kernel will crash during boot at around the point where savecore is
run with `vm_fault failed'.

I have tried to change USRSTACK to a very large value (VM_MAX_ADDRESS,
I think).  This produces a kernel that works, but since the stack
moved ps does not work properly (it cannot find the `ps strings' at
the top of the stacks, which causes it to print `(command)' for all
commands rather than the actual command lines); also, I noticed that
`sendmail -q' coredumped.  So this me to the conclusion that I have to
recompile at least ps and sendmail with the new value of USRSTACK.
There may be many other commands that need recompiling.  My question
is now: are there any problems besides this tied to redefining
USRSTACK?  I realize it probably breaks Sun3 compatibility, but I
don't care about that.

-- 
Per Bojsen                                   Email: pb@delta.dk
DELTA IC Design                                     bojsen@moria.home.id.dtu.dk
Venlighedsvej 4, Hoersholm, Denmark