LCE: Realtime, present and future [LWN.net]

LCE: Realtime, present and future

Posted Nov 15, 2012 10:26 UTC (Thu) by tglx (subscriber, #31301)
In reply to: LCE: Realtime, present and future by alejluther
Parent article: LCE: Realtime, present and future

Your assumption is, that Xenomai, RT-Linux and RTAI are fulfilling the requirements of hard real-time. I agree that the RTOS code base part of those is small, but it's complex enough that I have serious doubts about the ability to formally verify them.

Aside of that all those systems are so interwoven with Linux itself, that you'll have a real hard time to prove that there is no undesired influence possible from the "idle task Linux" to the "safe RTOS". Just look at the obvious lack of fault isolation and explain me how that is fulfilling the requirements.

While Preempt-RT might look more complex in the first place, I dare to claim that building an hybrid system, which fully relies on facilities of the "idle taks Linux" in all its glory without having full isolation in all aspects, is just introducing a different level of hard to understand and hard to verify complexity.

As long as nobody can point me to real proof of why any of the above solutions is verifiably more real-timeish than Preempt-RT, I definitely stand to my word, that Preempt-RT will make those obsolete or already has done so at least partially.

Thanks

    tglx

(Log in to post comments)

LCE: Realtime, present and future

Posted Nov 15, 2012 13:00 UTC (Thu) by simlo (subscriber, #10866) [Link]

Everytime this discussion comes up I add a comment like this:

Safety critical != hard real time

Safety critical means that the system is certified and verified and maybe even mathematical proven to be correct. This implies small code and very often hard realtime.

Hard real time means that there per design is an upper boundary to latency. But we all know that a system might not work as designed. Therefore a system can be hard real time by design but fail due to bugs.

Thus by these definitions neither preempt realtime, RT-Linux nor Xenomia can be be safety critical but all can claim "hard real time" - but only if they have made sure that all code paths blocking scheduling of higher priority tasks and interrupts, have an upper boundary.

And for a practical note: The theoretical upper boundary is not magnitudes higher than what you can measure in tests.

LCE: Realtime, present and future

Posted Nov 15, 2012 17:29 UTC (Thu) by tglx (subscriber, #31301) [Link]

I'm well aware that safety critical != hard real-time.

Though hard real-time systems must be designed in a way that they guarantee not to ever miss a deadline, simply because missing a single deadline is considered a fatal full system failure. So how do you guarantee that by other means than by mathematical proof?

> And for a practical note: The theoretical upper boundary is not magnitudes higher than what you can measure in tests.

None of those systems including Preempt-RT can specify their theoretical upper boundary, except in safe ranges which make them not at all different :)

Thanks
tglx

Most systems also have no proof that a kernel panic won't occur.

Posted Dec 9, 2012 7:41 UTC (Sun) by gmatht (guest, #58961) [Link]

Even for a non-RT system there is usually no proof that a full system failure won't occur. E.g. Linux has no proof that a kernel panic won't occur. Systems that claim to conform to POSIX standards rarely have a proof of this. If some organisation can trace all the cases of system failure to hardware failures they may choose to trust claims made by software, including hard real time claims, without formal proof.

LCE: Realtime, present and future

Posted Nov 15, 2012 13:24 UTC (Thu) by alejluther (subscriber, #5404) [Link]

Thomas,

That's a good point. But I talked about RTAI or RTLinux because the Xenomai reference. My experience is with RTLinux internals and the virtualization made there is just the simplest one, so you do not have isolation. You know there are today solutions based on full virtualization even with hardware help which, I guess, is a must for real full isolation.

The good part of RTLinux technique (I think RTAI did not follow the rule of "keep simple" strictly) is you can use it with some microcontrollers which will not have support for hardware virtualization.

Don't take me wrong. I think you are doing a fantastic job and with your mindset, maybe you prove me wrong in the future. I just wanted to point out the challenge (probably) needs another revolution regarding kernel design. By the way, the kernel modularity could be the starting point.