Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>> still need some means to prevent the scenario you described above.
>> Actually, all you need is some callback when the mapped memory block was
>> actually released (munmap/application exit). Such a callback can be
>> registered inside the rtdm_mmap handler as a vma_fileop.
> I have never worked with vma_fileop... I would need to learn it first.

Here is the patch to offer you access to those ops. Revert the previous
version, then apply this one. It still needs some final documentation
notes and a test on kernel 2.4. But is should already work on 2.6.

I also attached a demo for the handler usage based on my previous test
framework. Just grab the pattern and put some useful code in the close
handler...

>>  It will run in
>> non-RT, and could be used to mark the related hardware buffer as finally
>> free for re-allocation.
> Now, I did realize that there is one more problem on my current design.
> If the user application exits or is terminated, I'm not sure if the
> close handler is called if the user forgot/was not able to. If it is
> not, the buffer would be marked as used until I reloaded the driver...
> Is the close handler invocated on application termination?

Yep, this is a general issue you cannot avoid: all skin objects besides
task are only released when the user-space application cleans it up as
it's ought to. There is no tracking of used resources, no auto-cleanup.
If your application fails to close a device or socket, you will get a
stalled handle which can be found in /proc/xenomai/rtdm/open_files.
Writing the file descriptor number to this particular proc-file (e.g.
"echo 3 > /proc/xeno...") will trigger an enforced close and will
release the file descriptor again. Useful when debugging such broken
applications.

Jan