On Mon, Jan 30, 2006 at 12:00:24PM -0800, Garrett D'Amore wrote:

> As Izumi-san recently pointed out, there is a problem with my current approach 
> of conditionalizing the size of paddr_t on 64-bit platforms.  The problem is 
> that LKMs are likely to be impacted.  (Most of the userland tools work fine, 
> which was my original concern.)
> 
> Therefore, I'd like to follow one of two approaches, and I would like feedback 
> on which to follow *sooner* rather than later.
> 
> Option one: make paddr_t 64-bit on all evbmips platforms (basically modifyin 
> <machine/types.h>).  The current thinking is that this will not adversely 
> impact any "current" hardware that has R4K style MMUs.  What I'm not sure is 
> whether or not there is any desire to include future additional MIPS parts in 
> the evbmips port that this would cause a problem for.  Apart from 
> compatibility, there is the concern of increasing the size of the kernel, but 
> I consider this concern rather negligible.
> 
> Option two: separate out the Alchemy parts into a separate port (aumips).  The 
> main objection to this, I think, is additional complexity that it would 
> create.    A few kernel bits could be simplified a bit, since at that point 
> you don't have to consider e.g. 64-bit procs and compatibility with malta.
> 
> I would like to reach a decision on this as soon as possible.  My preference 
> is to just change the paddr_t size across the entire evbmips port.

Option three could be: Have two sets of LKMs for the evbmips port, one 32-bit
paddr_t and one 64-bit paddr_t.

I still think there is no reason to separate out the Alchemy port to
a separate port.  This issue of needing 64-bit paddr_t could possibly
apply to the MIPS64 Malta parts as well, so we'd end up moving most of
evbmips elsewhere and still not have acheived anything.

I think that option one is probably the best to go for.  A while ago I
tried using 64-bit paddr_t on an Alchemy board and a simple benchmark of
"build tcsh over NFS" was the same for both 32-bit and 64-bit paddr_t
for multiple runs - any time differences were lost in the noise.

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/