On Mon, 2003-02-24 at 19:24, Ian Romanick wrote:
uint_fast32_t actual_flags; /** Memory property flags of the memory * holding the buffer. */ uintptr_t offset; /** Offset of the buffer within the memory * heap.
Means careful checking is needed so someone doesnt load bogon values into an offset or object id and have fun.
I don't fully understand. Who would be the "someone" in this case? This data structure is only used internally by the client-side driver. The internals of this data structure (or even the locations of these structures!) isn't visible (without major hacking) to applications.
3.3 How does a process map from a memory address to a block ID? (open)
Surely its now file_handle->block not pid ?
Actually, I need to close that issue. This is what I'm putting in the document:
Drivers track buffers using driMemoryBuffer objects. The block ID that is believed to be associated with that memory is stored in the object. Beyond that, the heap_id (stored in the object) is used to select which array of memory_buffer structures to check, and the offset (also stored in the object) can be divided by the amount of memory each memory_buffer structure represents to determine which element in the array to examine.
3.4 How are block IDs reclaimed if a process crashes? (open)
if its file handle by handle close
Right. The catch is that, as proposed, the in-use block IDs are just tracked by a set bit in the vector. There is no track of WHO is using the ID.
3.15 How are pinned blocks reclaimed when a process dies? (open)
Each process can have numerous block pinned. These can either be framebuffer type objects or other objects that are temporarily pinned so that a fence can be set. The whole point of pinning an object is to prevent it from being reclaimed. However, if the process dies without releasing the blocks, the system must reclaim them.
The kernel has to track these anyway, and deal with making sure claiming the wrong blocks isnt fatal (consider one process corrupting anothers data in the shared space)
Corruption of the shared space, both the existing SAREA and the new proposed ones, is a problem no matter what. It's basically a trade of safety for performance.
I think that the answer is to somehow associate each "thing" that needs to be cleaned up on exit with the device handle. Hmm...
With regards to the bitmaps. You can speed stuff up a lot by doing
if(test_bit(foo, uppervector)) { for(i=0;i<32;i++) { if(!test_bit(i, realvector[foo])) { set_bit(i, realvector[foo]); if(realvector[foo]=0xFFFFFFFF) set_bit(foo, uppervector): } } }
and cut the search down. There are other structures that work safely too
Jeff and I had discussed the possilibty of using a heirarchical bitmap. The only problem is that in order to do that we would have to have a mutex on the bitmap. Since there's only 64K *bits* in the vector, it shouldn't be so much work to search the whole thing. I implemented a similar thing in an in-kernel communication protocol on ptx once. You can do a neat trick using cmpxchg to search of clear / set bits without using a "heavy" mutex.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
