eeh@netbsd.org writes:
> When a process image is exec'ed, it's address space 
> is constructed based, not on the current soft limits, 
> nor the current hard limits, but those constants.  
> So if that architecture allows 1GB for the stack 
> size, 1GB of address space is reserved for the stack, 
> even if the limits currently allow for only 2MB.

As I recall, the direct use of hard limits is (in a limited way) for
the data segment, and (in a more serious way) for the stack.


Text size limit is checked against the executable; as i recall the the
limits doesn't matter except in determining if the executable can be
run.

Max Data size is used to select locations for data mmap'd without an
address preference.  So the space covered by the max data size
starting at the data segment won't typically be used, but can be by
fixed address mapping requests.  It's not _turly_ reserved.

However, for stack, the space actually really is reserved -- the
currently available chunk, and the part between that and the hard
limit.

I don't recall the reasoning behind that -- it's been a fair number of
years since I looked at the code, and they've been busy years.  8-)
I seem to recall that it's related to the method and requirements for
what happens when you actually hit the soft stack limit.


Anyway, the point of this is:

(1) text size limit can pretty much be increased arbitrarily.

(2) data size limit presents a bit of a problem, because if it's _too_
large mmap-non-fixed mappings will have a hard time being satisfied
(in fact, IIRC, the mmap code won't _ever_ place non-fixed mappings in
that range).

(3) the stack size limits present a real problem, but I don't remember
what it is.  8-)



chris