I finally had a chance to look at the new pmap_procwr() function,
and I'm concerned it may not work as presently implemted on any
Sun machine with a context-dependent VAC.  (Sun3, Sun4, Sun4C)

The old code worked because the ptrace stuff was careful to
always switch to the context of the child to change anything.
With that no longer the case, pmap_procwr() on any Sun VAC
would need to switch the VAC to the proper context before
making any changes.  (Note: VAC has multiple H/W contexts.)

One question:  Why do we not continue to ask the common, MI
code to switch to the child context while making changes?
The current way seems to require more MD code...

Gordon Ross

Ignatios Souvatzis writes:
 > On Fri, Feb 26, 1999 at 12:26:07AM +0100, Ignatios Souvatzis wrote:
 > > implement. The interface is:
 > > 
 > > pmap.h:
 > > 
 > > #define PMAP_NEED_PROCWR
 > > void pmap_procwr((struct proc *p, vaddr_t start, size_t len));
 > > 
 > > implementation to your taste.
 > 
 > Oops.
 > Implementation:
 > 
 > do whatever is needed to make a previous write the the address space of
 > p, range [start, start+len), visible to p's instruction stream.
 > 
 > (For CPUs with merged instruction and data caches, nothing. 
 >  For CPUs with split instruction and data caches, typically some variant of
 >  flush data cache corresponding to that address range, then purge instruction
 >  cache corresponding to that address range will do.
 > 
 >  I write 'struct proc *'... so I guess non-snooping SMP machines will do
 >  this globally, if applicable.)
 > 
 > Regards,
 > 	Ignatios Souvatzis
 >