Ok, but it's up to the programmer and libraries to stay away from system
calls, as they turn the application into a soft real time one anyway.
> 2. page fault - stacks can cause 'em even after mlockall
That's what I was afraid of... Cannot this be fixed in any reasonable
way? (Is it related to dynamic stack allocation?)
> 3. any other trap or error condition that puts us in K mode.
Does this need to be handled without losing the RT timing, or is it
"just" a matter of handling it to keep RT an error condition from
causing a bad crash?
> The methods I've thought of for doing this are unpleasant.
What's the biggest problems here? Too much context info to keep track of
in order to separate RT from standard Linux? I'll have a closer look at
the low level areas of the standard scheduling code to get a better idea
of what's going in, but I'm not expecting a pleasant surprize...
//David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/