On Thursday 21 April 2011 20:43:33 Rebecca Schultz Zavin wrote:
On Thu, Apr 21, 2011 at 5:55 AM, Marcus Lorentzon wrote:
On 04/21/2011 02:15 PM, Arnd Bergmann wrote:
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.
My mistake, but still, ints could use an array too, and idr or lookup in general should not be an efficiency problem anyway.
- 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.
The idea of passing global ids should not affect lifetime. These ints are still lifetime controlled by the "fd" device that created them. So I think they do have a defined lifetime, that of whatever device this int is registered in. And if the process is shut down, all buffers registered in the drm/v4l2 device fd will be released and even freed if it was the last ref. And if you mean lifetime while process is still alive, even fds has to be closed, and ints has to be closed/unregistered using ioctl. And this is not something that is used by applications either, these refs and allocs are handled by the user space drivers, like libEGL / libGL / X-drivers etc, so ioctl vs. close should not matter.
The problem isn't managing their lifetime in the side that created the buffer, it's managing it while they are in flight. What happens if process 1 passes a buffer to process 2 and before process 2 takes a reference to it, process 1 crashes? Some central clearing house has to handle that. I'm guessing that's the X server in the X case. In my proposal that's handled by the extra reference being held by the passed fd itself (ie the kernel has a reference as long as the file struct exists in either processes file descriptor table).
I don't see a real problem here. Buffers would be ref-counted in the kernel. If process 1 crashes before process 2 gets to take are reference to the buffer, the reference count will be decreased to 0 and the buffer will be freed. Process 2 will then receive an error when it will try to take a reference to the buffer.