1 / 22

Real Time Linux Operating Systems

Real Time Linux Operating Systems. Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory Iowa State University swamis@iastate.edu. Linux as a Real-Time OS. Traditional RT Systems used custom built systems – which were not extensible I.e. tough to develop new applications

urania
Download Presentation

Real Time Linux Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Real Time Linux Operating Systems Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory Iowa State University swamis@iastate.edu

  2. Linux as a Real-Time OS • Traditional RT Systems used custom built systems – which were not extensible I.e. tough to develop new applications • However, as technology improved, generic real-time OS became acceptable • In OS suited for extensible development Linux looks more appealing

  3. Linux (and its Real Time versions) are free!! Linux (and its Real Time versions) are Open Source!! Easy for developing RT applications Why Linux?

  4. Why not Linux? • Linux didn’t have any corporate support until now • Linux, is a very good general purpose operating system, but not so for real-time OS (Why??) • Because, the design motive of a conventional OS and RTOS is different

  5. Linux as your real-time solution? • Could increase priority for “real-time” tasks and assume they get scheduled • Problem – Linux optimizes average case whereas an RTOS should work under worst case assumptions

  6. Linux – A Simplified View

  7. Linux – conflicts with RT constraints • Coarse grained synchronization – long intervals when a task has exclusive use of data ( as fine grained – leads to lot of overhead reducing the average case performance) • Linux batch all operations for efficient use of H/W • E.g freeing a list of pages when memory is full reducing the worst case performance • Linux doesn't preempt low-priority task during system call • Linux will make high priority tasks wait for low priority to release resources

  8. Real Time Linux approaches • Modify the current Linux kernel to guarantee RT constraints • Used by KURT • Make the standard Linux kernel run as a task of the real-time kernel • Used by RT-Linux, RTAI

  9. Modifying Linux kernel • Advantages • Most problems, such as interrupt handling, already solved • Less initial labor • Disadvantages • No guaranteed performance • RT tasks don’t always have precedence over non-RT tasks.

  10. Running Linux as a process of a second RT kernel • Advantages • Can make hard real time guarantees • Easy to implement a new scheduler • Disadvantages • Initial port difficult, must know a tremendous amount about underlying hardware • Running a small real-time executive is not a substitute for a full fledged RTOS

  11. RTAI Overview • Based on Real-Time Hardware Abstraction Layer (HAL) (also used in Windows NT) • HAL exports Linux data and functions related to hardware • HAL defines an interface between RTAI and Linux

  12. RTAI – A Simplified View

  13. RTAI Overview (continued) • Software architecture • Interface to Linux hardware management (HAL) • 3 basic components: dispatcher, scheduler, fifos • 1 interface used in user tasks to initialize and start the components • RTAI is basically an interrupt dispatcher (reroutes interrupts to Linux if necessary) e.g: Disk interrupt

  14. KURT Overview • Developed at University of Kansas • Soft real-time system • Refines the temporal granularity of Linux • Motivation: RT tasks may need a time resolution on the order of microseconds, while non-RT tasks may need a resolution of only milliseconds • Result: Timer interrupts are programmed to service earliest scheduled event (results in aperiodic timer interrupts)

  15. KURT Overview (continued) • Not suitable for hard real-time systems • KURT can’t guarantee priority of RT tasks over non-RT tasks • An RT task can be blocked by a non-RT task (eg: during disk I/O) leading to priority inversion • Suitable for soft RT systems

  16. RT-Linux Overview • Open source Linux project • Supports x86, PowerPC, Alpha • Patch of the regular Linux kernel (simply install the patch and recompile the kernel) • Provides an RT API for developers • Runs Linux kernel as lowest priority process

  17. RT-Linux Task Structure

  18. RT-Linux Interrupt Dispatcher

  19. RT-Linux Overview (continued) • RT tasks are coded as modules • Modules are inserted and removed at users discretion • Extremely good at handling periodic tasks • Communicates with non-RT kernel and other RT tasks via fifo queues • Tools are provided for graphical analysis of RT execution

  20. Problems with RT-Linux • Currently no support for aperiodic tasks • Not very useful for complex RT systems • Currently limited to simple problems

  21. Montavista – A Faster Response Linux Kernel • Montavista Inc. provides a linux solution for embedded systems • The solution’s aim is to make the Linux kernel fully preemptable • It identifies the points where priority inversion occurs in Linux and makes those points fully preemptable • A good embedded solution not a complete RT solution.

  22. Important References • RT-Linux : http://www.rtlinux.org • RTAI : http://www.aero.polimi.it/projects/rtai/contrib.htm • Montavista: http://www.mvista.com

More Related