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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
