GEM/TTM interfaces

[Tomas C. <to...@db...>]

I have read (don't remember where) that once the kernel has a sensible 
infrastructure for file descriptors you'd want to convert all the ioctl 
code in GEM/TTM to standard syscalls. Is that true? Do you already know 
which syscalls would replace for example drmBOCreate() or the GEM_CREATE 
ioctl? Both functions create a new handle, so open(2) would be a 
candidate, but both functions also take a 'size' argument, which open 
doesn't support, so you'd still have to implement an fcntl/ioctl 
interface for such things. But I'm not a kernel guru so there might be a 
better syscall then open.

On a related note, are there plans to merge the TTM and GEM APIs (the 
stuff that can be shared between the two)? From what I read in the vivid 
discussions here and on other mailing lists it doesn't seem that there 
is a clear winner. Also, for different situations different 
implementations might be required. So keeping both, at least for the 
time being, seems the way to go. But it's currently quite cumbersome to 
test both APIs, because you have to switch between the branches. Why not 
create an common interface that both TTM and GEM could implement and 
extend upon? Something like libdrm/dri_bufmgr.h in the drm-gem branch 
which I think tries to achieve this. This would allow you to have both 
memory managers in the same tree, and yet not interfere with each other. 
This would be to great advantage to users willing to test your code and 
also allow easy extensibility in case a third, even better, memory 
manager evolves in the future. However, in the dri_bufmgr interface I 
don't see any way to have the userspace check which memory manager the 
kernel module supports - which I think is important if the two memory 
managers are to live in the codebase at the same time. In my local tree 
I have added the basics of such interface. It basically allows the 
userspace query which MM the kernel module supports, and then based on 
that load the correct userspace counterpart. Would you be interested in 
such code?

cheers
tom