| Victor Yodaiken on the past, present, and future of RTLinux |
Victor Yodaiken (August 12, 2000)
Victor Yodaiken, project leader for RTLinux, is considered by many to be the father of "real-time Linux." In this interview with LinuxDevices.com founder Rick Lehrbaum, Yodaiken shares his thoughts about the past, the present, and the future of RTLinux. Where did RTLinux come from? What's new in the upcoming version 3 release? What new and exciting RTLinux enhancements can we expect to see over the next 12 months? What about the recent efforts to standardize real-time Linux? Oh yes, and one more thing . . . What's with that RTLinux patent?
Part 1: RTLinux -- the Past
RL: Could you provide a brief history of RTLinux? Where did it come from? How did the idea for RTLinux arise?
Yodaiken: I was interested in real-time for quite some time, and I was particularly interested in how to fit real-time into an operating system properly. I had also been doing some work on how to prove programs to be correct, program verification, which I think is eventually going to be critical for real-time systems.
RL: You were doing this as an instructor or professor at New Mexico Institute of Technology (NMT)?
Yodaiken: I came up with RTLinux at NMT, but I had been working on realtime and related issues even back to my graduate student research. I started working at real-time programming to get a feeling for what were the hard things to understand, and it came to me that one of the hardest and most difficult things in trying to validate that a real-time program works, was to show that the non-real-time components didn't interfere with the real-time components. This led me to think about how you could make sure this didn't happen.
Also, I was getting involved in Linux at the time, some of my students were working on the PowerPC Linux port. I was very happy with Linux. So, being interested in Linux, and being interested in real-time, and trying to figure out a way that you could make programs reliable by separating out the real-time and non-real-time parts . . . they all came together, and I thought of this 'trick' for running Linux as a sub-thread of the real-time operating system and 'fooling' it about what was happening with the interrupt controller.
RL: It's a brilliant technique! Really, it's one of the most elegant things you can do with computers because, in fact, they simulate hardware in software.
Yodaiken: Some of the complaints we got about the patent [more about the RTLinux patent, later] were from people who said "this is so obvious that it's obviously been done before," and I really sympathize with that because when I thought of this idea I thought, "this is so obvious that either someone did it before, or there's an obvious reason why it won't work". Having known about virtual machines, which is a very old idea, predating actual real computers, I was sure that someone had done this. The closest I found was actually something I had known about, an operating system called MERT that was done at Bell Labs in the '70s.
RL: What did the MERT developers do? In what ways is RTLinux similar or different from what had been done before?
Yodaiken: They did an entire virtual layer that ran a real-time operating system on top of an emulation of most of a processor. That was the big difference from what other people had done with virtual machines [before]. In many ways, the innovation in the RTLinux method is that it emulates such a small part. Everybody knew you could do this kind of stuff with virtual machines, but [the perception was that] virtual machines were very slow (or needed special hardware as in the IBM mainframes). The nice thing about RTLinux is that we only have to emulate this tiny little piece of the hardware [the interrupt controller]. Everything else can go on the raw hardware -- all the Linux I/O, all the general purpose systems I/O, goes directly to hardware. We don't have to emulate all that, we don't have to emulate very much at all. We just have to emulate this one little piece -- interrupt control.
RL: How long did it take you to unplug yourself from the university, and "go private"?
Yodaiken: It took a long time, and actually RTLinux development really slowed down, because after we'd done the first versions I got drafted to be the department chairman. So I spent 2 years doing RTLinux in my very, very short amount of spare time. I had all this idiotic administrative work, I was teaching, and I have a wife and children I like to see sometimes too, so I had almost no time to work on RTLinux. So development was pretty slow for a while. Finally I decided that I really had to devote myself full time to RTLinux. I've been on leave [from the University] and working on it full time only since January [2000].
RL: Are you expecting to go back to the academic environment, or do you think you'll stay commercial?
Yodaiken: I have a lot of research interests that I'd still like to work on at some point, but making RTLinux an 'industrial strength' product will come first. I'm going to stay with the company [FSMLabs] as long as it takes for that, full time. If I can keep one foot in academia at some point, that would be nice. But my agenda right now is I want to make RTLinux 'industrial strength' and want to make FSMLabs a going concern that's on its own feet and not necessarily dependent on me anymore. We're growing pretty fast, so I think we will get there.
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
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed