Part 3: RTLinux — the Future

RL: What are we likely to see in terms of new developments for RTLinux over, say, the next year?

Yodaiken: We're going to provide real-time networking. We have a very strict subset of the Internet protocol (IP), and possibly UDP, and we want to make it possible to layer on top of that, especially for applications that need QoS (Quality of Service). There, we're looking at applications like machine control, moving video, VoIP (voice over IP), telecom, fault tolerance, and clusters.

RL: Did you see the announcement from Lineo of the real-time networking support?

Yodaiken: This is the release by David Schleef. It looks good and takes the immediate pressure off us to release something. I think for many applications it will be enormously useful. Our network initiative is focused in a different area. For instance, we'd like to have a networking system that has hooks for QoS and types of quality service guarantees.

RL: Other plans?

Yodaiken: We want to do some fault tolerance tied into the networking. Also, we want to do some other ports, a MIPS port is underway, and probably a StrongARM port will be next, although SHARC is also interesting.

RL: Have you given some thought to supporting more of the wide variety of system-on-chip devices that are now available? (see article)

Yodaiken: The problem is, there are so many of them! We want to encourage and help independent developers and manufacturers to make RTLinux work on these systems. For many of them, RTLinux should run straight off. We don't have too much of a driver problem [since most of the hardware is controlled by Linux]. If the interrupt controller is compatible, we're fine. For many of the processors, those are on-chip, so it's not a problem. The problem with ARM and MIPS is that there are so many variations of the cores and of the controller devices, and ARM itself has some difficulties getting good Linux performance.

RL: Anything else?

Yodaiken: Yes, we're looking at making a standalone RTLinux that can run without Linux entirely. [We'll add] a little bit extra initialization and self-support, so we can make a ROMable RTLinux that can come up first, or that can stand alone on a very small system.

RL: Would it replace the BIOS?

Yodaiken: We actually could be part of the BIOS. We could take RTLinux, and mix it in with a BIOS of some sort. Have the BIOS do the initialization, just as Linux does the initialization for us now, and then pop up into RTLinux as the operating end of the BIOS.

RL: Would you expect RTLinux to be used without Linux, in that case?

Yodaiken: Yes. It doesn't mean that the same POSIX api that you use in Linux would be available without Linux. There are two uses for standalone RTLinux. If you really have to squeeze something down to a small size, MiniRTL will run happily in 4M right now, but we have some interest in seeing it run in smaller spaces with less functionality. The other use is in fault tolerant systems: if you have the RTLinux that could run on its own, if [the Linux kernel] died, you would still have some usable system there. Alan Cox proposed, as a joke, that a realtime thread could do a pthread_join on the Linux thread and reboot Linux on a crash — but I like the idea, for real.

RL: What if you need device support? Would you have access to functions like a Linux driver for IDE hard drives?

Yodaiken: What you'd do is put in what you needed. One of the goals has been to keep everything modular. You can have a bare system that you can put in a ROM, that does nothing other than touch a serial line every now and then. But if you want to put in IDE [drive support], you can do that too. If you wanted to put in IDE capability by calling the BIOS, that would not be that hard to do.

RL: So the mechanism for calling BIOS functions is not too complicated?

Yodaiken: No, I don't think so.

RL: Would it be easy to use Linux drivers?

Yodaiken: Modifying a Linux driver to work with RTLinux is not very difficult right now. It's still a job that requires “by hand” work, and we're hoping to move beyond that. But it's not a very hard job to do that.

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.