Re: Extending pmap_kenter_pa and pmap_enter.

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

matthew green <mrg%eterna.com.au@localhost> 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