On Wednesday 20 April 2011, Marcus Lorentzon wrote:
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.
File descriptors don't use idr.
- 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 ;)
The problem with passing an integer is that it doesn't have any concept of ownership or lifetime rules.
If you allow any process access to all integers, a malicious process might be able to guess it unless you use long cryptographic random numbers.
When you have a file descriptor, you can assume that the object is still alive until you close it. With an integer passed by some other application, that is less clear.
- 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()
In the idr example, the modules all need to link to the code that provides does the DEFINE_IDR(), in the file example, they only need to provide the same interfaces, so the modules need not link against any common code other than the VFS.
Not a major point though.
Arnd