uma_small_alloc from direct mapped memory.

[Juli Mallett]

On Mon, Dec 6, 2010 at 02:25, Jayachandran C. <c.jayachandran at 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.  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 — 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) — 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.