Jan Kiszka wrote:
Brian L. wrote:
How could I forget mlockall? I've been calling it in rtai forever...Is
there any other neccessary boilerplate?
This is a very frequently made mistake. Philippe, is there a chance add
some simple debug check for this situation? Something to check when the
first shadow thread is created for a process?
The following patch would cause SIGXCPU to be sent to emerging real-time
threads from a non-fully mlocked program (i.e. not including
MCL_FUTURE). We should make this conditionally compiled too. I'm not
sure that we would not introduce problems when dealing with mmio areas
mapped in user-space at least for older kernel revisions (the VM_IO
issue might have been fixed in recent kernels, though), this is why I
would tend to make it easy to work around this check by simply ignoring
the signal, for handling specific init configurations for which people
know what they are doing.
--- ksrc/nucleus/shadow.c (revision 875)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -754,6 +754,9 @@
+ if (!(current->mm->def_flags & VM_LOCKED))
Xenomai-core mailing list