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