On Sunday 20 March 2005 12:37, Nicolai Haehnle wrote: > On Sunday 20 March 2005 18:07, Lourens Veen wrote: > > ...the kernel tells it which process currently holds the DRI > > lock. Whenever the lock is obtained, the kernel (via PIO or direct > > DMA) writes the new value to the "current owner" register, ensuring > > that any write commands are filtered according to who currently > > holds the lock. Since you can only draw when you hold the lock, this > > would ensure that a process can never read or write outside its > > window. > > Once the video memory has been mmapped, the userspace process can do > with it whatever it wants, including accessing it while it doesn't > have the hardware lock. > > So the only way to force it would be to unmap video memory whenever a > process gives up the lock and fault it back in only if the process > owns the lock. I don't know if there's any precedent for something > like this in the kernel.
There is: cluster mmap. The lock would have to be kernel based, and passing it would be a really heavyweight operation, but this doesn't kill the idea. > Besides, you'd only want this for window > security, and window security has deeper issues even if you don't > mmap the video memory. Assuming that we use ownership test and extend it to reads, which deeper issues would those be? Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
