-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Burge wrote:
> 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.
The problem here becomes one of management.  If you don't have a way
to name these differences (e.g. by using a different port name), how
do you distribute them?  evbmips-eb-paddr64 ? Yikes.
>
> 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.
The MIPS64 stuff is going to be a problem, I think, almost no matter
what.  I cannot see that evbmips can properly encompass both a 64-bit
and a 32-bit kernel.  (Note that this is different than the 64-bit
part running in 32-bit compatibility mode.)
>
> 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.
So can I take this as approval to go ahead and make that change, so
that paddr_t is 64-bits on all evbmips?

- --
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBQ96Ub/49Sp1nAoU7AQI5fwgAgOEtKv0HwFvddlSjITXUHoStkmd4FCbe
mKeuQgTnHzik603yLp9FxiF7IFF769qBysVpfiqmG7xMSnpzk5b0LiU5lMySY9I2
QMmafbB+WmWr4OzSyWGpc/eH1DsX6/dRMhE0zsS+9+gQgDuxLC0onoGfLEsPmli/
ZWME/doHgFzdykHAZAYu0TGULTVGkfczshZvGfA6sdwWnIehBwtUbeli2FYlZwoW
LHLU7FehX7xSZ99miYMTykdupNxWEAI2o4Ek50ZshiZck2ctLupd9m4ZBEDN5s/q
bFOEiHBlKeB02Ivz8IXxBnZryAkgGNTBWxIvoJ9tk+4z4w35/z+2GQ==
=+BTH
-----END PGP SIGNATURE-----