From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 10:58:34 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1291F1065695 for ; Mon, 6 Dec 2010 10:58:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9EB38FC19 for ; Mon, 6 Dec 2010 10:58:33 +0000 (UTC) Received: by gyf3 with SMTP id 3so6236008gyf.13 for ; Mon, 06 Dec 2010 02:58:33 -0800 (PST) Received: by 10.90.120.20 with SMTP id s20mr7545344agc.132.1291633113040; Mon, 06 Dec 2010 02:58:33 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.236.108.51 with HTTP; Mon, 6 Dec 2010 02:58:12 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Mon, 6 Dec 2010 02:58:12 -0800 X-Google-Sender-Auth: 8KwNB-ORAdpZwXz9XMgb7PneOpI Message-ID: To: "Jayachandran C." Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 10:58:34 -0000 On Mon, Dec 6, 2010 at 02:25, Jayachandran C. wr= ote: > I was planning to merge these changes. Now that the XLR platform code > changes and 8-STABLE merge is done - I hope to get some time to do the > rest of the n64 work. My rough todo list is : > > - 64bit PTEs which will give >4GB phys address, I'm very excited about that; on Octeon it will mean that we can participate in the networking/messaging subsystem from userland, which I know will be very valuable for a lot of applications. > - 32 bit compat in n64 (merge from /user/jmallett/octeon) You probably don't want to spend much time on those changes; they were incomplete and focused on n32-on-n64. I know n32-on-n64 would be good, but is it your highest priority? o32-on-n64 will be easy because it's just like on other architectures. o32-on-n32 and n32-on-n64 require a complementary set of conditionals in the freebsd32 code to handle (in the former case) pointer size being unchanged and (in the latter case) register width being unchanged. I think we actually need to consider alternate compilation strategies for the freebsd32 code, such as filling it with ifdefs and #including the source files with different definitions so we can include o32 and n32 compat together on n64 kernels. > - Complete merge from /user/jmallett/octeon - UIO, sf buf Great :) > - DDB/KDB fixes for n32/n64. For what it's worth, DDB seems mostly complete on n64 these days, save for some issues in the trace code =97 I think we took the machdep ddb code from NetBSD and now that they support n32 and n64 I think we may just want to merge from them, no point duplicating that effort when the code is so crufty, complex and massive already. Maybe talk to bde@ or freebsd-arch@ or freebsd-hackers@ about the DDB changes required for n32 (and get someone to review the change to ufs to not use register_t where it mean uintptr_t / vm_offset_t) =97 some of the cleanups to be had there are good, but I think that there is some resistance to changing DDB just for n32. I think it's a good idea, but I'm not sure e.g. whether it's better to adjust the DDB APIs that pass addresses to use vm_offset_t or uintptr_t, or to keep them passing register_t and to make code that takes addresses from registers (or register_ts) more careful about how it converts them, since probably other ABIs will come along where using an opaque register type as something that can be converted directly to a pointer is bad. Perhaps what we really need are more debugger-specific types. Something that might be a worthwhile sell would be to continue to pass register_t in those APIs and to introduce a call (that can fail) to map a register_t to an address usable by the debugger, that way we can also do clever things to avoid page faults within the debugger, in addition to doing the necessary casts on n32. That would benefit more than just MIPS. > - 16K pagesize (there were some patches from SoC, but it crashed for me) Do you want to support both 4K and 16K pages on all MIPS ABIs, or just n64, or make n64 always 16k and everything else always 4k? Thanks, Juli.