My thoughts on this:

In theory, I think memory protection (kernel/RTL or per-RTL-task)
would be possible, but it would complicate things quite a bit, and
probably involve a deep kernel hack. Protection == restricted
memory access, so the RTL kernel would have to deal with two or
more separate address spaces instead of one; the kernel address
space. I don't know how significant the performance impact would be,
but there would certainly be some of it, especially if many RT tasks
are running, and they have separate address spaces.

Nevertheless, I think memory protection would be useful, even if
it would slow down too much for the more demanding RT applications.
A special debug RTL version with separate Linux and RTL address
spaces would be nice... Even better if it could be used for
production systems. (I'd rather burn some CPU time than having any
bug blowing up the kernel.)

If the overhead of changing address spaces makes the jitter too big,
a early interrupt -> selecting tables -> delay to correct time sheme
could help. I slightly longer, but "stable" latency would probably be
acceptable in many cases.

Emergency exit? Just an idea: Insert a module that checks how long
the curently executing RT task have been running. If it has been
looping for more than it's specified maximum time, suspend it, and
send an error message somewhere. (This requires the ability for a
task to ask RTL about these things. Is this already supported?)
Use while developing and in production systems. Remove if you think
Murphy's a clueless pessimist. ;-) (Or if you can't take that the
watchdog task steals some cycles every now and then.)


//David

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

Reply via email to