Subject: 64-bit paddr_t (again, arrgh....)
To: None <email@example.com, firstname.lastname@example.org, email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 01/30/2006 12:00:24
As Izumi-san recently pointed out, there is a problem with my current appro=
of conditionalizing the size of paddr_t on 64-bit platforms. The problem i=
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 feedb=
on which to follow *sooner* rather than later.
Option one: make paddr_t 64-bit on all evbmips platforms (basically modifyi=
<machine/types.h>). The current thinking is that this will not adversely=20
impact any "current" hardware that has R4K style MMUs. What I'm not sure i=
whether or not there is any desire to include future additional MIPS parts =
the evbmips port that this would cause a problem for. Apart from=20
compatibility, there is the concern of increasing the size of the kernel, b=
I consider this concern rather negligible.
Option two: separate out the Alchemy parts into a separate port (aumips). =
main objection to this, I think, is additional complexity that it would=20
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 preferenc=
is to just change the paddr_t size across the entire evbmips port.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)
-----END PGP SIGNATURE-----