Subject: 64-bit paddr_t (again, arrgh....)
To: None <port-evbmips@netbsd.org, port-mips@netbsd.org, simonb@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 01/30/2006 12:00:24
--nextPart1220395.CbdWYXVLpK
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


As Izumi-san recently pointed out, there is a problem with my current appro=
ach=20
of conditionalizing the size of paddr_t on 64-bit platforms.  The problem i=
s=20
that LKMs are likely to be impacted.  (Most of the userland tools work fine=
,=20
which was my original concern.)

Therefore, I'd like to follow one of two approaches, and I would like feedb=
ack=20
on which to follow *sooner* rather than later.

Option one: make paddr_t 64-bit on all evbmips platforms (basically modifyi=
n=20
<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=
s=20
whether or not there is any desire to include future additional MIPS parts =
in=20
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=
ut=20
I consider this concern rather negligible.

Option two: separate out the Alchemy parts into a separate port (aumips).  =
The=20
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=
=20
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=
e=20
is to just change the paddr_t size across the entire evbmips port.
=2D-=20
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

--nextPart1220395.CbdWYXVLpK
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)

iQEVAwUAQ95wYv49Sp1nAoU7AQKW/ggAhoolhffPRKJXus+7N8EVAJgbq1xb7ITe
ScN4W4BBsSF8ZZbopuqWk3Q+/Dwua/vc3sduEXdz8ckGdHcnec7jwj2FfcL5Fqbb
Tvy+AR0o+/aJRhiTjuRUFKJEzOvzq05HX1Gu0HWQfYuQckUBAhmWdILEU4dE3y/+
cdNdNRPcaBq76Ctc9FpKI1gR35plyA44YjrP/4IBGzXJQVrfaqcPwXSKnarIkCFM
03BRl8pq8IR9M1GTY1K4h52HQPd4pAzB/4sLt/5kvennk7PVAF6QZklyZgm5tJGo
HIYnSXqDqnvcjnZ7HZftfpO9Atb0cG4oqANfjB4NbnJcGSurzD3/Fw==
=l1s5
-----END PGP SIGNATURE-----

--nextPart1220395.CbdWYXVLpK--