Subject: Re: question about pmap_enter()
To: John Valdes <j-valdes@uchicago.edu>
From: Allen Briggs <briggs@ninthwonder.com>
List: port-mac68k
Date: 06/06/1999 17:28:08
[ I am also Cc:'ing to the person who submitted the GNATS PR... ]

> What should be used for access_type?  I tried copying the flags passed
> to prot:

That's the easiest solution.

>         pmap_enter (pmap_kernel(), 0x52040000, 0x52040000,
>                     VM_PROT_READ | VM_PROT_WRITE, TRUE,
>                     VM_PROT_READ | VM_PROT_WRITE);
> 
> and that *seems* to work OK.  The addresses mapped w/ pmap_enter() are
> only tested (read), eg:
> 
>     asm ("tstb      0x52040000 | disable writeback cache");
> 
> Does that mean access_type should only be VM_PROT_READ (or does it not
> really matter in this case)?

It doesn't really matter in this case, but I'd say that you'd be just as
well off to use VM_PROT_READ for both.

Can you (or someone else) take a look at something with these patches?
I ran across these patches while browsing through the PRs and there's
one drawback to getting them into the repository.  They'll break on
systems that don't have a Daystar installed.  Scott might have other
ideas, but I see basically three approaches:

[ In any of them, you'll have to probe for a Daystar by checking to see
  if a read to any of the memory locations generates a bus error. ]

	1) (my favorite) If there is no Daystar, map a single page of
	   memory over the 5 pages where the Daystar lives, then use
	   the same code everywhere.  It's a minor hit on systems that
	   don't have a Daystar, but it keeps everything pretty clean.
	2) Bracket each flush, etc., with a "if (daystar_installed)"
	   conditional.  I don't like this because it clutters the code
	   in several places and it's more expensive to test and branch
	   than to simply read a memory location.
	3) For each function that uses the _flush_daystar, provide one
	   version that does and one version that doesn't, and call
	   through a pointer instead of calling the function directly.
	   I don't really consider this an option since we have #1.  It
	   makes things far more complicated than they need to be and it
	   gives you no savings over #1.

Other (minor) nits...  I wouldn't make these full functions--a jbsr to a
subroutine that basically just does a tstb will take many more cycles.
This will be obsoleted by the changes I suggest, but as a note...  It's
not necessary to '.globl _flush_daystar' more than once in locore.s.  ;-)

Make sense?  Comments?  Thoughts?

-allen