Quoting Daniel Vetter (2019-11-06 10:21:57)
> On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > the file pointer into the backend mmap routine. Now that we can create
> > fully fledged anonymous struct file around the drm device, put it to
> > use.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > ---
> > drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > 1 file changed, 8 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 0814211b0f3f..5faa63713ec8 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > */
> > int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > {
> > - struct drm_file *priv;
> > - struct file *fil;
> > + struct file *file;
> > int ret;
> >
> > if (obj->funcs && obj->funcs->mmap) {
>
> obj->funcs->mmap is the new way of doing this (and hopefully finally
> something clean), I'd really like to retire the below hack outright.
>
> Plus I'm not sure why you need an anon inode here? If a driver needs this
> for unmap_mapping_range or similar I think it'd be better to try and make
> something work cleanly for obj->funcs->mmap.
It's faking one currently. If the fake is not good enough, you are
playing whack-a-mole until you finally do create a fully fledged file.
If you are going to the trouble of having to create a struct file to
provide to the fallback routines, might as well avoid stinky code :)
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
