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

[Cherry G. Mathew <cherry%zyx.in@localhost>]

Hi Matt,

>>>>> "matt" == Matt Thomas <matt%3am-software.com@localhost> writes:

    >> 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.

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

This turned out to be a very excellent suggestion - it actually caught a
couple of places in MD where uvm_physseg_init() was in the wrong place.

See: http://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem/src.diff


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

Sure - I haven't looked at his yet - and don't intend to in this iteration.

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

Committed.
http://mail-index.netbsd.org/source-changes/2016/12/22/msg080080.html


-- 
~cherry