On Thu, Feb 28, 2002 at 09:46:48PM -0000, eeh@netbsd.org wrote:
> |
> | By moving things around in VM, it's possible to shrink the hole to the
> | maximum stack size, which is usually less than the maximum data size.
> | But by removing sbrk/brk entirely, it's possible to eliminate it
> | altogether.
> 
> I don't think that's at all correct.  If you ever use sbrk(), whether
> in the kernel or emulated, it needs to extend the data segment, or
> you lose its semantics.  Since we use dynamic libraries, and the 
> dynamic linker uses mmap() without MAP_FIXED, those mappings need to
> be somewhere where they will not conflict with possible emulated
> sbrk() calls.

One extremely frustrating thing that's been going on in this discussion
has been the presumption on many people's part that just because we might
include code that *can* emulate an obsolete system call, all users forever
and anon *will* build their systems to include such code.

In point of fact, almost none of my systems ever include COMPAT_ options
for older versions of NetBSD; I suspect that most people who *do* include
such options either don't actually need them (but include them because
*all* of our example kernels, even the ones for tiny embedded boxes like
the Soekris where it's extremely unlikely anyone would ever try to run an
ancient binary do), or could easily arrange to not need them.

For one-level-page-table architectures like the VAX where support for
sbrk() effectively has the entire pmap twisted into absurd knots, wouldn't
it be nice to not be *forced* to build your system that way?  If you want
to support ancient binaries, then fine, you can have the ancient datasize
restrictions; elsewise, don't have them.

Thor