On Wed, Nov 6, 2019 at 11:43 AM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Quoting Chris Wilson (2019-11-06 10:26:48) > > Quoting Daniel Vetter (2019-11-06 10:19:50) > > > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote: > > > > Sometimes we need to create a struct file to wrap a drm_device, as it > > > > the user were to have opened /dev/dri/card0 but to do so anonymously > > > > (i.e. for internal use). Provide a utility method to create a struct > > > > file with the drm_device->driver.fops, that wrap the drm_device. > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > > For proper internal access we already have drm_client_open, so I think > > > this has limited (but good use) in selftests only. So > > > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended > > > use like drm_file_mock_open? > > > > I found the example in drm_gem_prime_mmap() that was doing the same trick, > > and the trick of being able to instantiate new struct file and install a > > fd whenever seems like it will come in handy... Just lacking the third > > user at the moment to claim generality. > > The closest example I found in the spirit of creating a new drm_device > struct file and installing it is drm_mode_create_lease_ioctl() that uses > file_clone_open() for this purpose. The argument there would be whether > cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate > versus an anonymous inode. I think cloning the credentials seems correct > for leasing. Hm ... I think we want the clone for this one here too. Otherwise we get the wrong inode, and then unmap_mapping_range wont work correctly, and we cant use this for selftests. That's the only case where I think we do actually need the file/inode to be functional. For anything else the drm_client internal api gets away without the file/inode stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
