*** Regarding Re: Changing USRSTACK; Bernd Ernesti
*** <netbsd@arresum.inka.de> adds:

Bernd> I had the same expierence if I increased the size of MAXDSIZ to
Bernd> 128MB and got the same error. Now I am using it with 96MB for
Bernd> MAXDSIZ and MAXSSIZ, but I think it should be enough to use
Bernd> 32MB for MAXSSIZ and 128MB for MAXDSIZ.

Yes, I chose these values myself yesterday.  These leave a gap of up
to 64MB between top of the data segment and bottom of the stack.

Bernd> You don't care about it but I do that and I think others do it
Bernd> also.  So keep the USRSTACK and make the stack size indepenend
Bernd> from the data size as some other ports do that now: alpha,
Bernd> arm32, i386 and vax.

I realize that some people care about Sun3 compatibility, but that
shouldn't prevent me from changing the value.  After all, I have the
source :-) I'd just like to know whether there are any known problems
(besides having to recompile some system utilities, such as ps) with
changing USRSTACK to VM_MAX_ADDRESS, say.  The relatively low value of
USRSTACK limits the address space you can use for mmap'ed files, at
least between the data and stack segments, if you also want higher
than standard values of MAXDSIZ and/or MAXSSIZ.  I noticed that ld.so
did not like to be mapped above USRSTACK, although mmap() has no
problem with mapping above USRSTACK.

I wonder if there are any (other) problems with mmap'ing above
USRSTACK?  If malloc() was changed to exploit the VM system better,
one could work around the barrier that USRSTACK represents.  *If*
exploiting the space above USRSTACK is safe, that is.

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