Allen Briggs writes:
> [ I am also Cc:'ing to the person who submitted the GNATS PR... ]
[...]
> Can you (or someone else) take a look at something with these patches?

I'm willing to give it a try, but I'm more of an applications
programmer, not a kernel hacker (well, so far, at least... ;) ) and
don't really understand everything that's going on in the patched
files (nor how to implement some of your suggestions below).  And the
only assembly I've ever programmed was Z80... :)

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

As it stands, it *does* require that one define "options DAYSTAR" in
the kernel config file and build a new kernel, which presumedly one
wouldn't do if one didn't have a Daystar installed, but yes, I see
your point that it may be desirable to have a Daystar patched kernel
work in a system w/o a Daystar (eg, just in case one ever had to
remove the Daystar for some reason).

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

This seems reasonable.

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

Agreed.  Every little bit of speed that can be squeezed out will be
good.  :)

John