Subject: Re: ptrace
To: Ignatios Souvatzis <is@jocelyn.rhein.de>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 02/16/1999 14:30:46
I dont like the name much;) -- on mips, the operation is explicitly a
flush, not a synch -- but its the right solution.  Trying to overload
the operation on uvm_io or page mappings and remappings means a) we'd
have to flush the entire page out of the icache, and b) we'd ahve to
do ite very time, even when the common case is that the contents of a
text page doesn't change.

Just for maintenance (hp-pa port?), i'd sooner force all ports to
provide a definition (as part of the pmap?) and make it a no-op on
ports where it's truly a no-op.

And if the 68040 and 060 need this for gdb, then they may well require
a similar cache synch for gcc's closure-building code: at least on
mips, that writes a code thunk onto the stack and jumps through it.
So the mips userland cache-flush code is in libc -- its part of the
mips ABI, gcc can generate it on the fly, and on mips, the cache
flushes cannot be done from userland (yuck).

BTW, where should the manpages for mips cachectl() and cacheflush()
(from lib/libc/arch/mips/gen/) go?  If the 68k supports those
operations, maybe they'd make a better API?