Guennadi Liakhovetski wrote:
On Sat, 25 Aug 2007, Calin Culianu wrote:
Now, there is no way to raise the priority of particular driver's ISRs is
there? So that a specific ISR can preempt anything including a hard realtime
process?
It's the second time you say "hard" real-time, so, just wanted to warn -
it is not hard. It is still only soft real time, but a pretty good one, I
think.
I don't know what exactly "soft real-time" is, and I don't think there
is an exact definition of it. The term "hard real-time", however, is
well defined. It is the same as "real-time". It means that a system
never ever exceeds a previously defined maximum latency. If, for
example, you define 100 microseconds as such, you run your system over a
long time period (several days), and you observe several billions of
single external events that trigger a user space process at real-time
priority, then there must be no single event that fails to do so within
100 microseconds. We did this constantly and successfully with an -rt
kernel. So why are we not allowed to call this "hard real-time"?
If you are aware of a situation where this is not the case, then this
may be a specific problem related to a specific situation. Please help
us to improve the -rt patches further and submit a bug report. I am
confident that it will be fixed as soon as possible.
--cbe
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
