Re: Help with a bug in mmap

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 31 Oct 2018 23:16:49 +0100
> From: Kamil Rytarowski <n54%gmx.com@localhost>
> 
> On 31.10.2018 18:05, Taylor R Campbell wrote:
> > For the moment, as a provisional workaround to make progress, you can
> > probably get by with `pa << PGSHIFT', where pa is the physical (byte)
> > address of the page you want -- but make sure to add a big scary XXX
> > comment saying that this is not right and needs to be fixed.
> 
> Is this scary XXX because of internals or driver code? We intend to make
> it a model driver, so we prefer to do the right thing in the first
> place, especially making it MI.

I don't think we have a good way to do this at the moment, so there
are two ways to proceed if this is supposed to be a model driver and
not a prototype for which `pa >> PGSHIFT' will serve for now:

1. Determine whether this is a sensible thing to do overall, and
   invent an MI API for it.  (A priori, I'm not sure it is sensible to
   just map kmem pages into uva; I would need more context to assess
   this.)

2. Use a custom fileops to specify a custom mmap routine to specify a
   uvm object, rather than just handing out device paddrs in d_mmap.
   You can get the uvm object with uao_create.  To map it into kva,
   you can use uvm_map.  This is considerably more involved than a
   mere cdevsw::d_mmap function.  For an example, see
   sys/external/bsd/drm2/drm/drm_cdevsw.c.  (Ignore drm_legacy_mmap;
   I'm not even sure why that's still there.)  Your xyz_fop_mmap
   function will just return the uao you created for the device.