Date: Tue, 7 Dec 2010 14:59:27 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: Alan Cox <alc@cs.rice.edu>, freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. Message-ID: <AANLkTi=21=XaTUiZjP4LGQEv%2BV98HEb1b30Q9qs5fQiG@mail.gmail.com> In-Reply-To: <AANLkTikgDZVPd7PCZp94Jn-XdNcy72bswZth56qdc2yO@mail.gmail.com> References: <AANLkTi=Rn_L%2BLtGyAay7HJQco6ne-WgRxri-BH=A9q1m@mail.gmail.com> <AANLkTinfMTmPh1UrS1PauQonCDVBgE_0mbb0zP2w3L6W@mail.gmail.com> <AANLkTinJaFsnooR=JfPffUJwGS=7qinvoBFmK5ENq0J7@mail.gmail.com> <AANLkTikgDZVPd7PCZp94Jn-XdNcy72bswZth56qdc2yO@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 6, 2010 at 4:28 PM, Juli Mallett <jmallett@freebsd.org> wrote: > On Mon, Dec 6, 2010 at 02:25, Jayachandran C. <c.jayachandran@gmail.com> = 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=21=XaTUiZjP4LGQEv%2BV98HEb1b30Q9qs5fQiG>