Part 4: RTLinux and real-time standards

RL: What do you think about the various proposals for a real-time Linux standard that are floating around?

Yodaiken: The intention with RTLinux version 3, is that you can write RTLinux threads in something that looks very much like user-land threads environment. What we've done over the last year, starting from version 2 which gave us the initial pthreads environment, is to integrate the POSIX threads/signals calls into our existing set of operations. So one example is if you want to catch an interrupt in version 2 (also supported in version 3), you make a call to rtl_requestirq. But in version 3 there's an alternative way to do this which is to use sigaction, which is the standard POSIX call.

What we would like is for programmers who come to the RTLinux environment, and are familiar with the pthreads and POSIX programming environment, to have very little difficulty in figuring out how to write RTLinux programs. We would very much like them to not have to learn a new environment, and also particularly not have to learn much about how Linux works internally.

We don't want to force programmers to do Linux kernel programming. We want them to write things that are nice and straightforward like threads programs. There are two reasons: one is that people should not have to learn the complexities of Linux internals, which is always changing and is a very complicated environment; and the other is that real-time programming is hard enough without having to learn something else. So we want to give people a familiar environment to work in.

RL: So that's the impetus for using POSIX as the real-time function interface in RTLinux version 3?

Yodaiken: Yes. The POSIX 1003.13 specification allowed us to conform to POSIX without having the performance compromises that you get if you go for the more heavyweight POSIX environment. The 1003.13 specification defines four classes of POSIX environments, ranging from a very minimal real-time-only system (called a PSE51, the “minimal real-time environment”) all the way up to a full fledged POSIX system which is both real-time and non-real-time (PSE54), which is essentially what Linux is. PSE51 looks like a single POSIX process per processor with applications as threads and signal handlers. By focusing on PSE51, we get the familiar environment of the POSIX threads programming interface, but we don't have the performances compromises that we'd have to have if we went to the full-fledged POSIX environment. I'm really speaking about things like putting in POSIX file I/O, which there's no way to do in hard-real-time.

RL: So it sounds like POSIX 1003.13 in general, and PSE51 in specific, fit the RTLinux architecture very nicely.

Yodaiken: Yes. We've preserved what I think is the biggest advance in RTLinux which is this paradigm that you separate out the real-time parts very vigorously from the non-real-time parts, you decouple the operation of the two components. We don't let the non-real-time interfere with the real-time. That's at the core of RTLinux. And we've kept that while being able to have this nice familiar environment of the POSIX threads and signals.

What we realized, was that we could conform to POSIX standards *and* get a POSIX api without destroying our core value of this decoupling. With the decoupling, we get the performance. With RTLinux we always quote worst case interrupt response times, and the reason we're able to do that is because the very complex and sophisticated non-real-time environment can't delay the real-time system. We had avoided POSIX in the past, because POSIX seemed to make us mix all these things together. But the 1001.13 environments specification allows us to make a very simple real-time environment with a more complex environment, the Linux environment, as a sub-thread.

RL: Is anybody else implementing PSE51?

Yodaiken: I think we're the first to actually implement it, and we're the only people who are actively pushing it right now.

RL: And it's an approved standard?

Yodaiken: Yes. What's nice is that we found an existing standard that we can fit into, without compromising performance. There is a real standards body. The standard is not the creature of any one particular company. It's not the whim of anybody's agenda. The standard is technically exactly what we needed, and we're very happy to find that and to work with that framework.

Continued . . .

Story navigation:
Part 1: RTLinux — the Past
Part 2: RTLinux — the Present
Part 3: RTLinux — the Future
Part 4: RTLinux and real-time standards
Part 5: “The Infamous RTLinux Patent”

---

Related stories:
Real Time Linux for Embedded Systems in the Internet Era
An Introduction to RTLinux
FSMLabs releases RTLinux Beta V3.0 Hard RealTime Linux
RTLinux is Patented?
New RTLinux release (V2.2) extends POSIX compliance
FSMLabs developing RTLinux for Compaq Alpha AXP
RTLinux V3.0 beta available for download
RTLinux.com
RTLinux: a real-time Linux
The RTLinux Manifesto

---

Do you have questions or comments on this article? talkback here

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.