Re: MMIO regions

["Benjamin C.R. LaHaise" <blah@kvack.org>]

On Mon, 4 Oct 1999, James Simmons wrote:

> On Mon, 4 Oct 1999, Benjamin C.R. LaHaise wrote:
> 
> > On Mon, 4 Oct 1999, James Simmons wrote:
> > 
> > > And if the process holding the locks dies then no other process can access
> > > this resource. Also if the program forgets to release the lock you end up
> > > with other process never being able to access this piece of hardware.   
> > 
> > Eh?  That's simply not true -- it's easy enough to handle via a couple of
> > different means: in the release fop or munmap which both get called on
> > termination of a task.  
> 
> Which means only one application can ever have access to the MMIO. If
> another process wanted it then this application would have to tell the
> other appilcation hey I want it so unmap. Then the application demanding
> it would then have to mmap it.  

GUG!  Think: you've got a file descriptor, if you implement an ioctl to
lock it, then your release op gets called when the app dies.  But
Stephen's suggestion of using the SYSV semaphores for the user code is
better. 

> > Or in userspace from the SIGCHLD to the parent, 
> 
> Thats assuming its always a child that has access to a MMIO region.

This is a commonly used trick in unix programming: at the start of the
program, you fork and perform all operations in the child so that the
parent can clean up after the child.

> > or if you're really paranoid, you can save the pid in an owner field in
> the
> > lock and periodically check that the process is still there.
>  
> How would you use this method?

man 2 kill.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/