Re: Portmasters alert: was => Re: uvm physseg - put the lid on it.

[Matt Thomas <matt%3am-software.com@localhost>]

> On Dec 19, 2016, at 12:19 PM, Cherry G. Mathew <cherry%zyx.in@localhost> wrote:
> 
>    Cherry> I believe, a more formal way to do this, would be to use the extent(9)
>    Cherry> API to manage all of the paddr_t space, thus formalising this
>    Cherry> relationship with consumers. I'm not inclined to look at this in the
>    Cherry> context of hotplug, due to "mission creep".
> 
> Committed a preview on -current:
> http://mail-index.netbsd.org/source-changes/2016/12/19/msg080026.html
> 
> Here's the "switch over" patch:
> http://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem/src.diff
> 
> These have been tested on various architectures by a few people, so
> unless there's vigorous disagreement, I will commit this once -current
> is stable again.

Don't add another uvm_* call to all ports.  It's just another things to do wrong.
Instead add a uvm_md_init and make it call uvm_setpagesize and uvm_physseg_init.
Thus if something new gets added we don't have to mung all the ports again.

You can't use extent for managing paddr_t space since extent uses longs and on
ports paddr_t is a long long.

Change uvm_physseg_valid to uvm_physseg_valid_p to show it's a predicate test.