Nick Piggin wrote:
Sorry James, we were talking about hard realtime. Read the thread.
hard realtime = mathematically provable maximum latency
Yes, you'll want a nanokernel for that, you're right. That's because one has to analyze every line of code, and protect against introduced regressions, which is almost impossible given the pace that Linux-proper
If you look at your first two messages in this thread however, you seem to be offering a nanokernel approach (in particular RTAI as suggested by Cristoph) as an alternative to the RT-patch. This is sort of confused by the fact that Ingo called it "hard realtime" because he measured a maximum latency during a stress test. Unfortunately that's not really hard realtime if you are just measuring it; Rather its "really damn good soft realtime". An analysis of code paths could be done to determine if something really does satisfy hard-RT constraints, but to my knowledge that's not on the table at this point. So you're discussing soft realtime if you're dicussing the RT patch.
So its really just a misunderstanding; Nanokernels certainly still have a place for some applications even with the RT patches applied (Ingo has said as much). However expecting audio applications such as Jack to have to use RTAI is kind of silly, and would end up annoying the authors of both (I'm sure the RTAI people have better things to do than support ALSA drivers in RT mode).
I really hope we understand each other now, but if not I guess it wasn't to be. Hopefully someone got something out of reading this discussion, but I won't be posting on this branch of the thread anymore either.