On 04/20/2011 06:19 PM, Arnd Bergmann wrote:
File descriptors have a number of very nice properties that we can use:
- Efficient lookup in system calls
If both use the idr I don't see how fds are faster than ints.
- Established ways to pass them around
What could be easier than passing an int? I just don't like the "feature" of passing fds where they are dup-ed without driver knowing so. If you want to store process specific info associated with the fd you have to use a list since you don't know if the app sends the fd to another process. Probably not a big deal, but I don't like it ;)
- Easy to mmap() -- if you want to map anything into user space, you need a file descriptor anyway
True, passing the local ids as offset is kind of messy.
- 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)
My experience says that you normally wait for device related events. But if the possibility exist, maybe someone can make use of it. Video events are mostly one per buffer (like frame decoded/encoded).
- 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
Global ids should also be "compatible", since they are from the same name space. But what do you mean by callbacks? In kernel API on buffer objects? If so, idr_find(ID)->buffer_struct->callback() should be similar to idr_find(FD)->file_struct->callback()
- 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.
Even if you use fds, I think these only replace the need for global ids, not local ids. Like GEM local id or V4L2 buffer index. And you really want to register the buffer only once, not every time it is used in an ioctl. So the driver/device accepting the buffer probably want to hold some meta data for its HW for each buffer. Like device MMU tables, device cache state etc. Having these local references will still force you to do clean up. For global ids/fds, I see no point in using them to hold references to the underlying allocation.
/BR /Marcus