> On Dec 19, 2016, at 12:19 PM, Cherry G. Mathew <che...@zyx.in> 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.
