Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.sys.m88k
Subject: Re: Read/write/execute Proposal
Message-ID: <3072@lupine.NCD.COM>
Date: 22 Dec 90 08:33:24 GMT
References: <1990Dec21.201522.16487@dg-rtp.dg.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 41

In article <1990Dec21.201522.16487@dg-rtp.dg.com> hamilton@siberia.rtp.dg.com (Eric Hamilton) writes:
+
+1) The operating system must know, at page replacement time, that a
+   particular page is potentially executable...
...
+I propose that we support read-write-execute pages by defining mechanisms
+that user applications may invoke to identify potentially executable
+data and to provoke cache writebacks and invalidates as necessary.
...
+We also need some way to notify the kernel that a piece of storage is
+potentially executable.  The following mechanisms come to mind:
+
+	- Add a MCT_RWX (state 4) argument to memctl().  When an area
+	  is memctl'd to MCT_RWX the operating system must treat it as
+	  potentialy executable for paging purposes.  This is probably
+	  the solution of choice in the BCS world.

+	- Use mprotect() in the V.4 world for the same purpose.

I frankly am having a hard time understanding what exactly this
discussion is all about.

I understand that it would be nice to have a "standard" way of telling
the OS that some part of the virtual address space is executable.  So
what?  As noted, in V.4 you will be able to use mprotect (or mmap) to
do this.

I see people talking about the BCS/OCS.  That's V.3 stuff!!!  Won't
the V.4 ABI will make that all obsolete (and also give you mprotect)
anyway?  If so, what's the big deal?  Is it really worth it at this
stage to be fretting about what the OCB/BCS does (or does not) say?

Obviously, it *is* worthwhile to make sure that the precise semantics
of mprotect() are suitable to meet a variety of needs, but why should
anybody be haggling (at this late date) about OCS/BCS changes?

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.