From owner-cvs-sys  Sun Dec 29 21:31:23 1996
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA01609
          for cvs-sys-outgoing; Sun, 29 Dec 1996 21:31:23 -0800 (PST)
Received: (from dyson@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA01602;
          Sun, 29 Dec 1996 21:31:22 -0800 (PST)
Date: Sun, 29 Dec 1996 21:31:22 -0800 (PST)
From: John Dyson <dyson>
Message-Id: <199612300531.VAA01602@freefall.freebsd.org>
To: CVS-committers, cvs-all, cvs-sys
Subject: cvs commit:  src/sys/vm vm_mmap.c src/sys/i386/include vmparam.h
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

dyson       96/12/29 21:31:21

  Modified:    sys/vm    vm_mmap.c
               sys/i386/include  vmparam.h
  Log:
  Let the VM system know that on certain arch's that VM_PROT_READ
  also implies VM_PROT_EXEC.  We support it that way for now,
  since the break system call by default gives VM_PROT_ALL.  Now
  we have a better chance of coalesing map entries when mixing
  mmap/break type operations.  This was contributing to excessive
  numbers of map entries on the modula-3 runtime system.  The
  problem is still not "solved", but the situation makes more
  sense.
  
  Eventually, when we work on architectures where VM_PROT_READ
  is orthogonal to VM_PROT_EXEC, we will have to visit this
  issue carefully (esp. regarding security issues.)
  
  Revision  Changes    Path
  1.57      +13 -1     src/sys/vm/vm_mmap.c
  1.22      +3 -1      src/sys/i386/include/vmparam.h