> [ many ideas about moving around the process address space ]
>> Of course, that juggle may come at a higher price than removing
>> sbrk.  That's a judgement call for you people to make.  I just point
>> out possibilities. :-)
> Thanks, I have tried to move around things a bunch already, just for
> test purposes (like letting all mmap() go in P1 space).

Duh, of course.  You can get the same effect as my (second) suggestion
without moving the stack just by putting mmap in P1 space just under
the bottom of the stack.

> The problem is that it's just workarounds for the bad mmap/sbrk
> interaction.

Well, that's a matter of attitude: is the mmap/sbrk thing a bug (or at
least a misfeature - is it removable), or is it something unpleasantly
difficult to support on the VAX that NetBSD nevertheless must?  Which I
suppose comes down to, how important are the precise traditional sbrk
semantics?  (Starting at _end and growing up contiguously.)  Certainly
if you support binary compatability with past systems you have little
choice but to support brk(), as old statically-linked programs that
malloc won't run without it (and when you get old enough there is
nothing but statically-linked).

Consider, by way of contrast, replacing the statement above ("The
problem is...") with "The problem is that it's just a workaround for
NetBSD's trying to be a UNIX".  Not that I'm saying that they're
equivalent, or that I agree or disagree with either one.  Just noticing
that your phrasing implies that convenience of the VAX port is more
important than implementing traditional semantics - and it may be true,
but it should be thought of as that tradeoff, which I don't think the
above tends to produce.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B