On Wed, Dec 22, 2010 at 11:13:52AM +0900, Masao Uebayashi wrote: > 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).