On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote: > So if we leave the lookup reference around from the GTT mapping ioctl, that > would take care of new mappings. And if we added/removed references at VM > open/close time, we should be covered for fork. But is it ok to add a new > unref in the finish ioctl for GTT mapped objects? I don't think so, > because we don't know for sure if the caller was the one that created the > new fake offset (which would be one way of detecting whether it was GTT > mapped). Seems like we need a new unmap ioctl? Or we could put the mapping > ref/unref in libdrm, where it would be tracked on a per-process basis...
Ah but maybe we should just tear down the fake offset at unmap time; then we'd be able to use it as an existence test for the mapping and get the refcounting right. The last thing I thought of was whether we'd be ok in a map_gtt -> crash case. I *think* the vm_close code will deal with that, if we do a deref there? Thanks, -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
