Approaches to realtime Linux
Posted Oct 14, 2004 5:02 UTC (Thu) by karim
In reply to: Approaches to realtime Linux
Parent article: Approaches to realtime Linux
Where the line is drawn between what is "visible" and what isn't for hard-rt processes can be configurable. That's not a problem.
What is a problem is introducing subtilities in the kernel's behavior that are so convoluted as to be too complex for the majority of driver and applications writers as it is. For the past five years I have been the maintainer of the Linux Trace Toolkit. For having done that work, I can tell you that only a marginal number of programmers actually really understand how the kernel operates, and how its operation is infuenced by or influences that of user-space applications and drivers. Just last July I was speaking with Jim Gettys at the OLS and he told me how he'd love to see something as LTT integrated into the kernel because most developers out there simply have no idea what they are doing. Not because they're careless or because they don't want to know, but because their expertise is elsewhere, and they shouldn't be expected to know that much about the kernel's behavior.
This is very relevant to the current debate. The fact of the matter is that the RTAI/fusion development model is much easier to work with because the traditional developers do not need to be exposed to an API that is unlikely to be of use to them (and if the API is there, they will use it; not because they are irresponsible, but because as carefull programmers they will try to give the best out of the kernel for their application), and because those who need it get all they need from a very targeted set of services. Again, as I said earlier, making Linux respond faster does NOT solve the problem of providing deterministic hard-rt, but providing deterministic hard-rt does allow Linux to respond faster.
As for drivers, then yes real-time drivers are different from normal non-rt drivers. There is absolutely no way that all Linux drivers will become suited for hard-rt system just by redefining a few macros here and there. Hard-rt drivers require a hard-rt mindset.
If all this is about making "multi-media" respond better in Linux, then the argument can easily be made that such critical components of multi-media system ought to be deterministic hard-rt anyway. Such multi-media applications can successfully use the services of Adeos and RTAI/fusion, real hard-rt applications can't use the "better latency" schemes. Why settle for less?
to post comments)