Keith Whitwell wrote:
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks..
Or is there something radeon specific about it I missed...
This ties in directly to the idea of a generalized memory manager for the DRI drivers, something that I should be able to get some time to look into fairly shortly.
It's not clear what is being allocated in the patch except for a unique number - what is the number used for after that?
It's supposed to be the surface number : it gives you a surface between RADEON_SURFACE0* and RADEON_SURFACE7* and then allows you playing with LOWER/UPPER.
There's already the equivalent level of trust exported to the clients in the existing interfaces to allow them to manage a shared bitfield themselves in the SAREA shared area using the drm lock for serialization.
The aspect missing from both your implementation and the SAREA-based bitflag is that there is no way to free bits in your bitflag which are held by contexts in processes which die without clearing their bits, eg. by segfault.
Hmm, I thought about this but wasn't sure if that was a problem. How can this be solved ?
Associate the allocated resources with the filp of the connection which was granted them (note: NOT the pid), and when that connection closes, deallocate the resource.
Keith
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
