Date: Mon, 7 Jun 2010 23:26:49 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: "C. Jayachandran" <c.jayachandran@gmail.com> Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips Message-ID: <AANLkTikFRSBpwdqy-66CTk2rClt9NZvF-IFVe8NCj80y@mail.gmail.com> In-Reply-To: <AANLkTilJm1RVd8TUZo55f9dU4ZeaC0UlShWHOn1AIdhD@mail.gmail.com> References: <AANLkTimIa3jmBPMhWIOcY6DenGpZ2ZYmqwDTWspVx0-u@mail.gmail.com> <AANLkTil2gE1niUWCHnsTlQvibhxBh7QYwD0TTWo0rj5c@mail.gmail.com> <AANLkTinA2D5iTDGPbflHVzLyAZW-ZewjJkUWWL8FVskr@mail.gmail.com> <4C07E07B.9060802@cs.rice.edu> <AANLkTimjyPc_AXKP1yaJaF1BN7CAGBeNikVzcp9OCb4P@mail.gmail.com> <4C09345F.9040300@cs.rice.edu> <AANLkTinmFOZY3OlaoKStxlNIRBt2G2I4ILkQ1P0CjozG@mail.gmail.com> <4C0D2BEA.6060103@cs.rice.edu> <AANLkTikZxx_30H9geHvZYkYd0sE-wiuZljEd0PAi14ca@mail.gmail.com> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <AANLkTilBxdXxXrWC1cAT0wX9ubmFrvaAdk4feG6PwDYQ@mail.gmail.com> <AANLkTimPm6A-nYG2AdNXeyA4ALnIVxEAJAUqPIDBN-T6@mail.gmail.com> <AANLkTilJm1RVd8TUZo55f9dU4ZeaC0UlShWHOn1AIdhD@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 7, 2010 at 23:13, C. Jayachandran <c.jayachandran@gmail.com> wr= ote: > On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett@freebsd.org> wrote= : >> Do you intend to support o32 kernels in your port indefinitely? =A0I >> wonder whether this work is just stopgap until the systems which have >> large amounts of RAM can just use n64 kernels. > > I think the page table work will be needed for o32 and n32, and I > would like to support one of them as the preferred 32bit mode for our > port. OK. > BTW, n32 with >4GB RAM can be supported with XKPHYS for page table > entries. The options there would be either special allocator for the > segtab (11+9+12 addr space split), or to use special allocator for all > the page table pages (10+10+12 split). Yeah, but we have a disinterest in supporting n32 kernels in base because it breaks assumptions in so many parts of the kernel, so I think the most reasonable expectation for base is to support o32 and n64, and to strongly prefer n64 for systems where it's more appropriate. >>=A0At least on Octeon it >> seems to me that n64-only is the right answer if at all possible, >> since there are really a lot of parts of the kernel that just can't >> reasonably work otherwise (use of rman_get_virtual with io ports, for >> instance.) > > Not sure I understand this part - I thought pmap_mapdev() would handle > these - but I may be mistaken. There's nothing pmap_mapdev can do on an o32 kernel with 32-bit PTEs for a physical address >2^36. (There are rather a lot of those on Octeon.) Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikFRSBpwdqy-66CTk2rClt9NZvF-IFVe8NCj80y>