Steven Rostedt wrote:
Hardware that is less complex is easier to mathematically prove that it will do what you expect to do in all cases, than hardware that is over engineered, just like software. I hold that PREEMPT_RT is not soft real time, but is hard real time designed. That is, we can't prove that it is hard real time, but any time we find a case that the software can break its deterministic result, it is a bug and needs to be fixed. (aka, a system failure).
Which serves to highlight my point about using these terms -- you're the terms "hard" and "soft" in a different way than a previous poster. (Assuming "hard real time designed" can get mistaken for "hard real time". You're saying it's hard because we intend it to meet system deadlines (regardless of deadline??), and it's a bug if it doesn't. The previous poster in this list was using it to imply guarantees of of very specific response times (< xxx us). You really, really have to talk about the specifics of the environment, the requirements, the application needs, etc. And I'm missing about half a dozen "really"'s there. thanks, Nivedita -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
