Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.sys.m88k
Subject: Re: Read/write/execute Proposal
Message-ID: <3091@lupine.NCD.COM>
Date: 25 Dec 90 02:19:26 GMT
References: <1990Dec21.201522.16487@dg-rtp.dg.com> <3072@lupine.NCD.COM> <1990Dec23.222149.9473@dg-rtp.dg.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 69

In article <1990Dec23.222149.9473@dg-rtp.dg.com> hamilton@siberia.rtp.dg.com (Eric Hamilton) writes:
>
>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.

Ignoring the V.3 world for the moment, let me just ask some innocent
(and naive?) questions and see what pops up.

First question:  When you say "the caches" are we talking about the
I and D caches on a single processor system, or are we talking about
more than that?

Let me assume for the moment that the problem that **most** (but admitedly
not all) folks are concerned about at the moment is the I/D coherency
for a uniprocessor.

Now please don't jump all over me if I've got my facts all confused, but
let me just toss out an off-the-cuff, top-of-the-head idea and see what
(if any) merit it might have.

Before I begin, let me say that it seems to me that (depending upon
the application and the frequency with which you are going to be
using these tricks) that it might be acceptable to alternatively
(a) write some executable code into an area, then (b) call mprotect()
to set the permissions on the area to include EXECUTE, then (c)
execute the code, then (d) call mprotect again to set the area back
to just read-write, then (e) start the cycle all over.

If this would work, then I would imagine that it would be pretty easy
to get vendors to sync the I/D caches at the point of each mprotect(EXECUTE)
call.

Anyway, assuming that the frequency at which this stuff has to happen
is too high to allow that (simple?) solution, how about this instead?
You have an area which is mprotected to allow write & execute... when it
is first setup that way, the OS maps those pages into the D address space
of the process (using mapping tables referenced by the DATA cmmu) but sets
those same pages (at the same logical addresses) as "unmapped" in the I
address space (using the mapping tables referenced by the INSTRUCTION cmmu).

Now I can write stuff in there and as soon as I try to execute any of
it I'll catch a page fault, right?

At that instant, the OS could swap the mappings (i.e. map the page IN TO
the I space and OUT OF the D space) and sync the caches.

I could now proceed until I tried (later on) to again treat the area as
data space, at which time I would again catch a page fault and the OS
could again swap the mappings back again.

Whatdaya think?

>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. 

Agreed, however we are getting into some rather low-level semantics here.
Is it possible to descend below the level addressed by the ABI and to
arrive at a level which so low that its issues can only be described
as "quality of implementation" issues?


-- 

// 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.