we still have a design flaw in mmap()'ing outboard memory into
userspace for MI drivers.

Look at, eg., syu/dev/tc/sfb.c The driver (*d_mmap)() entrypoint needs
to return a physical address.  The extant code kludges around this by
defining a `machine_btop()' which does the appropriate munging to get
the right return-type for a physical address.

But this still isnt really enough. MI drivers may, in principle, need
or want to set MD flags in the address -- for
uncached/write-trhough-write-back, &c, mappings

But there's no MI way to do this: some ports use low_order bits as
flags, some use high-order bits, and there's not even a standard
namespace of MI flags.

Worse yet, my misp3 kernels panic on the old pmax sfb.c driver,
because the unmanaged device pages arent getting the appropriate
PROT_* protection bits set in the address returned by the (d_mmap)()
entrypoint -- and IIRC, its MD whether those are encoded in the low or
high bits of the return value.


How about adding a new MI ``machine_btop(sysaddr, prot, flags)''
hook, with arguments

     sysaddr -- a system physical address,
     prot -- VM_port bits to set in the return value
     flags -- some MI-namespace of flags for TLB attributes,
             including but not limited to NOCACHE, WRITEBACK, WRITETHROUGH?
	     ( possibly more, eg. sun VME mappings...)		       

which returns the right MD value for a d_mmap entrypoint?

But what I'd *really*_ like to do is to be able to set a bit saying
``this PA is part of a contiguous physical region of 4Mbytes'', so
that the MD code can set up one giant TLB mapping for the whole
region.

This makes a noticeable difference to software blittign on mips3,
since you use one TLB entry for the whole framebuffer instead of one
per physical page.  That'd need an extra flag and a `region size'
argument. Should it be a different hook ( degenerating to a single
normal page-op on machines which dont support big pages) or a separate
hook?