matthew green <[email protected]> wrote: > > > I'd like to two add one more argument to pmap_kenter_pa > > and two more to pmap_enter. > > > > To pmap_kenter_pa, I want to add a vsize_t after the pa argument: > > > > void pmap_kenter_pa(vaddr_t va, paddr_t pa, vsize_t len, > > vm_prot_t prot, u_int flags); > > > > To pmap_enter, I want to add the same vsize_t afer the pa argument > > but also a struct vm_page * after the vsize_t. > > > > int pmap_enter(pmap_t pmap, vaddr_t va, paddr_t pa, vsize_t len, > > struct vm_page *pg, vm_prot_t prot, u_int flags); > > > > These charge are to take advantage of larger page table entries on > > those platforms that have them. Since pmap_enter implementations > > almost always do a PHYS_TO_VM_PAGE, and since the caller usually > > has it available, it might as well supply. If this is to be an > > unmanaged mapping (device page), then NULL will be passed for pg. > > since changing pmap APIs is pretty difficult and requires a lot > of coordination, i'd rather add new functions than change the > signature of the existing ones. > > we can also provide backup versions of the new ones for platforms > that don't have them yet by simply looping as necessary and/or > dropping the pg argument, based on __HAVE_PMAP_ENTER_WITH_LEN or so.
I strongly disagree. Yes, it requires some effort to get portmasters to implement the change request (at least, in this case, m68k does not have a zillion of pmaps). However, sprinkling #ifdefs will make the code more complicated, ugly i.e. more difficult to read, fragmented and it is against the direction we are going since netbsd-5 cycle. More complicated MD changes than the proposed one were done in the past and we could do this one (obviously, it goes into a branch). -- Mindaugas
