On Wed, Dec 22, 2010 at 11:13:52AM +0900, Masao Uebayashi wrote:
quoted text
> On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
> > 
> > On Dec 6, 2010, at 8:19 AM, Masao Uebayashi wrote:
> > 
> > > On Thu, Nov 25, 2010 at 11:32:39PM +0000, YAMAMOTO Takashi wrote:
> > >> [ adding cc: tech-kern@ ]
> > > 
> > > The basic idea is straightforward; always allocate vm_physseg for
> > > memories/devices.  If a vm_physseg is used as general purpose
> > > memory, you allocate vm_page[] (as vm_physseg::pgs).  If it's
> > > potentially mapped as cached, you allocate pvh (as vm_physseg:pvh).
> > 
> > Ewww.  How p->v is managed needs to be kept out of the MI code.
> 
> Could you elaborate the reason why so?
> 
> I've already proven that __HAVE_VM_PAGE_MD pmaps don't need struct
> vm_page *.
> 
> > There can be a common implementation of it for use by MD code but
> > that isn't the same as MI.
> > 
> > > Keep vm_physseg * + off_t array on stack.  If UVM objects uses
> > > vm_page (e.g. vnode), its pager looks up vm_page -> vm_physseg *
> > > + off_t *once* and cache it on stack.
> > 
> > off_t is not the right type.  psize_t would be more accurate.
> 
> Probably.

Well, I want to make this MI.  One of motivations to use vm_physseg
is to make page identity independent of machine-specific types
(paddr_t / psize_t).  So that kernel modules are shared between
different sizeof(paddr_t).

I see pmap as "MMU driver".  paddr_t is an opaque type, which should
be used only for H/Ws that touch the physical bus (mainbus).