| Part 3: RTLinux -- the Future |
Victor Yodaiken (August 12, 2000)
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
(Click here for further information)
|
|
|
FUEL Database on MontaVista Linux
Whether building a mobile handset, a car navigation system, a package tracking device, or a home entertainment console, developers need capable software systems, including an operating system, development tools, and supporting libraries, to gain maximum benefit from their hardware platform and to meet aggressive time-to-market goals.
Breaking New Ground: The Evolution of Linux Clustering
With a platform comprising a complete Linux distribution, enhanced for clustering, and tailored for HPC, Penguin Computing¿s Scyld Software provides the building blocks for organizations from enterprises to workgroups to deploy, manage, and maintain Linux clusters, regardless of their size.
Data Monitoring with NightStar LX
Unlike ordinary debuggers, NightStar LX doesn¿t leave you stranded in the dark. It¿s more than just a debugger, it¿s a whole suite of integrated diagnostic tools designed for time-critical Linux applications to reduce test time, increase productivity and lower costs. You can debug, monitor, analyze and tune with minimal intrusion, so you see real execution behavior. And that¿s positively illuminating.
Virtualizing Service Provider Networks with Vyatta
This paper highlights Vyatta's unique ability to virtualize networking functions using Vyatta's secure routing software in service provider environments.
High Availability Messaging Solution Using AXIGEN, Heartbeat and DRBD
This white paper discusses a high-availability messaging solution relying on the AXIGEN Mail Server, Heartbeat and DRBD. Solution architecture and implementation, as well as benefits of using AXIGEN for this setup are all presented in detail.
Understanding the Financial Benefits of Open Source
Will open source pay off? Open source is becoming standard within enterprises, often because of cost savings. Find out how much of a financial impact it can have on your organization. Get this methodology and calculator now, compliments of JBoss.
Embedded Hardware and OS Technology Empower PC-Based Platforms
The modern embedded computer is the jack of all trades appearing in many forms.
Data Management for Real-Time Distributed Systems
This paper provides an overview of the network-centric computing model, data distribution services, and distributed data management. It then describes how the SkyBoard integration and synchronization service, coupled with an implementation of the OMG¿s Data Distribution Service (DDS) standard, can be used to create an efficient data distribution, storage, and retrieval system.
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.
|
|
|
|
|
news feed