Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!uflorida!gatech!mcnc!rti!dg-rtp!siberia!hamilton
From: hamilton@siberia.rtp.dg.com (Eric Hamilton)
Newsgroups: comp.sys.m88k
Subject: Re: Read/write/execute Proposal
Message-ID: <1990Dec23.222149.9473@dg-rtp.dg.com>
Date: 23 Dec 90 22:21:49 GMT
References: <1990Dec21.201522.16487@dg-rtp.dg.com> <3072@lupine.NCD.COM>
Sender: usenet@dg-rtp.dg.com (Usenet Administration)
Reply-To: hamilton@siberia.rtp.dg.com (Eric Hamilton)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 75

In article <3072@lupine.NCD.COM>, rfg@NCD.COM (Ron Guilmette) writes:
|> 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.
|>
The discussion is about how to have read-write-execute semantics
in multiprocessor systems without requiring that the hardware support,
without software intervention, coherency between the instruction cache(s)
and the data cache(s).

This requires two things.  One is a way of notifying the OS that a given
area of memory is both writable and executable.  The second is a way of
bringing the instruction caches into instantaneous coherence so that
an application can write an instruction into an rwx region, do the
thing that brings the caches into coherence, and then execute the newly
written instruction.
 
|> 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.
|>
Not "nice" but "necessary", at least in the context of comp.sys.m88k;
it may be exactly the other way around in comp.arch.....


The mprotect() call gives us a standard answer to the first requirement
(telling the OS that a given area is executable) but not the second (bringing
the caches into instantaneous coherence).  A fast trap for this purpose
is at least discussably useful in both the V.3 and the V.4 worlds.
  
|> 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?
|>
The bulk of the discussion is relevant to both BCS and ABI.  It is true
that the ABI is closer to a complete solution because it has mprotect(),
and that a BCS solution is less interesting at this date.
A full ABI solution can be delivered with mprotect() plus a little bit more,
and a full BCS solution can be delivered by augmenting memctl() to
deliver the relevant mprotect() functionality, plus exactly the same little bit
more.

Thus, it may be reasonable not to worry about the BCS, but it is not the case
that the V.4 ABI will render the whole discussion obsolete, nor that the advent
of mprotect() alone will necessarily solve the problem or end the discussion. 

----------------------------------------------------------------------
Eric Hamilton				+1 919 248 6172
Data General Corporation		hamilton@dg-rtp.dg.com
62 Alexander Drive			...!mcnc!rti!xyzzy!hamilton
Research Triangle Park, NC  27709, USA