From owner-freebsd-mips@FreeBSD.ORG Tue Dec 7 09:29:30 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 5860D1065695; Tue, 7 Dec 2010 09:29:30 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AC7438FC12; Tue, 7 Dec 2010 09:29:29 +0000 (UTC) Received: by wwf26 with SMTP id 26so8906084wwf.31 for ; Tue, 07 Dec 2010 01:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YEBhov1fphH+efx6gc/Yc7/ac/Xh2U+WosPep+omtHA=; b=CJLzICYsNQItuOdGoKXjorH4j2O4qMyKZx6wH8ZcHkDnuVs6U7Wuq+HZOuXlhgJhW/ YSCT0VGUc0dk+iJf/QPvsQTlIHX43hInhBHjvyXnMvHeGoUyuZVaWeHLtzjXZ5RSxv8H dRA9ySmq4vpOuYXua0KgWIf/1m3B6qIhGkVKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hpaXJDZ4BOq+hwjP9WhhELAIpzoE2jwhG76vXc40PZgoUlbU02FgNpMRLDsOrMCLnS ZYRXFvgn5ITUtudwvEpt4e6OGD1PoXB2nKzfQad6jqv4TSfaLUQSLhAD0DrVIUqqq6CN ivFGlEXIprKtsy7QRFRYYGSUsTUNDEP+Hbtbs= MIME-Version: 1.0 Received: by 10.227.147.213 with SMTP id m21mr6928591wbv.131.1291714167280; Tue, 07 Dec 2010 01:29:27 -0800 (PST) Received: by 10.227.135.84 with HTTP; Tue, 7 Dec 2010 01:29:27 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Dec 2010 14:59:27 +0530 Message-ID: From: "Jayachandran C." To: Juli Mallett 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: Tue, 07 Dec 2010 09:29:30 -0000 On Mon, Dec 6, 2010 at 4:28 PM, Juli Mallett wrote: > On Mon, Dec 6, 2010 at 02:25, Jayachandran C. = wrote: >> 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. =A0I know n32-on-n64 would be > good, but is it your highest priority? =A0o32-on-n64 will be easy > because it's just like on other architectures. =A0o32-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. =A0I > 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. o32 on n64 is probably the most useful one, but I haven't looked at it in detail. I thought I would merge your code first and then understand what more is needed. >> - 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. =A0I 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. =A0Perhaps 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. =A0That would benefit more > than just MIPS. There are fixes needed in n64 too. But as you said, to do n32 correctly would be a lot of trouble :) >> - 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? I was thinking of a config option. The executables are already aligned at 64K, so the userspace should not be a problem. Last time this was discussed, someone noted that there was issues in earlier FreeBSD versions for large page sizes. I have the 16K patch booting, but the userspace crashes a lot and I did not get enough time to debug that. JC.