[EMAIL PROTECTED] wrote:
> The problem is, that on cards that lock up, we cannot rely on applications
> acquiring this lock. An mmaping/unmapping the framebuffer is the only way to
> ensure that an application can/cannot access the framebuffer.
Wait a minute. For me a 'kernel lock' is not acquired by the application
directly at its initiative. It is used _inside_ the kernel between various
parts of the kernel.
So, in fact, I wonder if it's possible to put a kernel lock on the fb-area
(the resource is the card memory) that can be used to enforce mutual
exclusion between the hw accel _driver_ and the memory mapping mechanism.
Understand that I have little understanding of how memory mapping works
especially in linux. More precisely, is there any kernel code executed
when an user-process writes in a memory mapped area or is it directly
handled by the MMU hardware?
If everything is handled directly by the MMU, then I guess you are
right and we have no mean of control. Once we have accepted to
memory map the fb into the userspace process adress space the only
way to prevent it (even temporarily) to access this area is to
unmap everything.
However, it seems to me that, for such memory mapping, some code
may be executed sometimes in the kernel, no ? Modern hardware is
so intelligent today that it can move pages between virtual
memory and a PCI device alone without any kernel intervention?
Well, I'll wait your answer before going any further...
Rodolphe
