Hi, > > >>Hmm, that looks like a rather strange way to return a file descriptor. > > >> > > >>What is the reason to not use ioctls on the vfio file handle, like > > >>older version of these patches did? > > >If I understood correctly that Alex prefer not to change the ioctls on the vfio file > > >handle like the old version. > > >So I used this way the smallest change to general vfio framework only adding a > > >subregion definition. > > I think I was hoping we could avoid a separate file descriptor > altogether and use a vfio region instead. What exactly did you have in mind? Put the framebuffer information (struct intel_vgpu_dmabuf) into the vfio region, then access it using read/write/mmap? > However, it was explained > previously why this really needs to be a separate fd and I agree that > using a region to expose an fd is really awkward. Now with this patchset we have *two* kinds of separate file handles. First the anon-fd created by reading from the region. This is then used to run the intel ioctls on, which in turn create the other kind of file handle (dma-buf-fd). The dma-buf-fd really needs to be a separate fd, because it gets passed around as handle and because this is the way dma-bufs work (guess this is the discussion you are referring to). I can't see a compelling reason for the anon-fd though. I suspect this was done due to a misunderstanding ... cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
