On Wed, 2010-09-15 at 14:48 +0200, Sergio Ruocco wrote: > Pradyumna Sampath wrote: > > I agree. Hard, soft ... far too qualitative for a discussion like > > this. Numbers, test cases and applications determine different > > meanings of these words. > > Right. Hard and Soft realtime discussions end up always in useless > infinite loops. The *applications*' *requirements* are hard or soft. > THANK YOU! The term "RTOS" historically has been a tag used by proprietary vendors to charge exorbitant fees for their OS. TODAY, with embedded shifting towards Linux, there are still a few of these RTOS vendors, who are using variants of this "fear tactic" with their customers: "Linux isn't an RTOS, and it won't be reliable" This is also key to Klaas's point that most customer's "think" they need an RTOS. That's typically good marketing to your typical organization where product management and marketing has been empowered to the point where they are making software architecture decisions. OTOH, there are plenty of valid applications for RT, don't mis-understand. Its just that RTOS is IMO just a totally overmarketed term to earn premium revenue. > These requirements reflect in the OS, the CPU, the IO devices, and more > typically a convolution of all of them, depending on what the > application does, i.e., the actual sequence of computations, OS > syscalls, IO operations and so on... > And the aggregate latencies either QUALIFY or DISQUALIFY the OS, based on some degree of qualification. That qual should be extremely rigorous for "hard RT" and may be less so for "soft RT". The notion that you can just buy a hard RTOS, that makes guarantees, and be done with things, is a fantasy. In the end you will be doing a lot of work on your RTOS (drivers), and you can screw things up badly. Or you can qualify Linux. If Linux is good, then you are done, otherwise, pay for an RTOS or send patches. Its that simple. Sven -- 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
