On Wednesday 20 April 2011, Marcus Lorentzon wrote:
On 04/20/2011 02:23 PM, Tom Cooksey wrote:
There's a big difference between GEM and what we're trying to do. GEM is designed to manage all buffers used by the graphics hardware. What I believe we're trying to do is only provide a manager which allows buffers to be shared between devices. Of all the buffers and textures a GPU needs to access, only a tiny fraction of them need to be shared between devices and userspace processes. How large that fraction is I don't know, it might still be approaching the 1024 limit, but I doubt it...
Why is it that everyone want it to be fds? It just put requirements on dup-ing the fds on IPC instead of sending a simple int. What is wrong with the GEM FLINK names? In STE HWMEM we use the same concepts as GEM with local device ids for buffers and exported global names (since we also planned to merge HWMEM with GEM when time permits). But kernel ioctl API is just one piece. Then we have a kernel internal API for other devices to use, like V4L2 drivers. These can then just use the global GEM FLINK name as input in a "register_gem_buffer_ioctl". Then the driver resolve and check rights for this name/buffer on register/import. And adding some in kernel API to GEM for resolving buffers from global names shouldn't need any big breaking changes or new revs of ioctl API.
File descriptors have a number of very nice properties that we can use:
* Efficient lookup in system calls * Established ways to pass them around * Easy to mmap() -- if you want to map anything into user space, you need a file descriptor anyway * Easy to wait for events -- if you want to wait for something to happen, you always need an fd to poll() on (this might not be necessary here, but in most subsystems, it comes up sooner or later) * Allows arbitrary subsystems to create compatible handles. Like a socket can be provided by unrelated subsystems, this file handle could be created by any of GEM, v4l, tmpfs, ... and we can have operations that each of them provides as callbacks * lifetime management: a process dies and do_exit() automatically closes the file descriptors, no need to clean up afterwards. See posix SHM vs SysV SHM, or posix message queues vs. sysv message queues.
Not using file descriptors basically comes at the cost of reinventing all these when we need them. IMHO, using files should be the first thing to look at and we only look for something else when there are very strong reasons not to use them.
Arnd