Small-footprint and Real-time Linux-esOperating System (OS) goalsWhat is out there?uClinux detailsSoft Real-Time Linuxes detailsWhen is Hard Real-Time needed?RTLinux: The Real Time LinuxRTLinux: MicrokernelRTLinux: Microkernel (cont.)RTLinux: Microkernel DetailsRTLinux: Real-Time TasksRTLinux vs. RTAIPriority Inversion and RTLinuxReferencesSmall-footprint and Real-time Linux-esAthanasios StathopoulosVladimir BychkovskiyOperating System (OS) goalsGeneric operating systems goalsprovide high level abstractionsimplicity of usefairness in schedulingapplication independencesome quality of service (QoS)Real-Time and Embedded OS goalsvery low latency (“real-time”) responsedeterminismsmall-footprintWhat is out there?Open SourceMicrocontroller (no MMU) OSes:uClinux - small-footprint LinuxQoS extensions for desktop:Linux-SRT and QLinux soft real-time kernel extensiontarget: media applications Embedded PCRTLinux, RTAI hard real time OSfully compatible with GNU/LinuxCommercial:vxWorks, QNX, HardHat Linux, WinCE, etcuClinux detailsProvidesCommon Linux APIFull TCP/IP stackPopular filesystems supportSupported platformsOriginally developed for Motorolla 68KLarge number of platforms currently supportedSpecial featuresKernel size < 512kbLimited multitaskingDesigned for portabilitySoft Real-Time Linuxes detailsLinux-SRTSingle QoS scheduler guarantees a CPU % for an application.Special features:real-time X server that prioritizes rendering based on scheduling parametersSupported platforms:same as main stream linuxSummary:User-orientedQLinuxCPU % guaranteed to groups using hierarchical scedulersSpecial features:additional schedulers for network, disk devicesSupported platforms:same as main stream linuxSummary:Research-orientedWhen is Hard Real-Time needed?Hard vs. Soft Real-TimeHard RT always guarantees exact timingHard Real-Time applicationsClosed-loop control systemsStimulus/response systemsExamplesRobotics, AnimatronicsIndustrial equipmentNeural, fuzzy and adaptive systemsHowever:Hard Real-Time extensions can degrade OS performance of non time-critical applicationsRTLinux: The Real Time LinuxGoalsmaintain compatibility with GNU/Linuxhandle tasks with hard-real time constrainssimplicity and reliability of the RTtradeoff: ease of useApproachreal-time microkernelLinux kernel is running as lowest priority task in the real-time schedulereal-time applications are written as microkernel modulesmicrokernel is transparent to regular applicationRTLinux: MicrokernelMicrokernelIS a thin layer of abstractionPROVIDES an interface for hardware interrupts and API for real-time tasksMEDIATES requests to/from hardwarePicture from www.embedded.com website.RTLinux: Microkernel (cont.) ComponentsProcessor clock controlReal-Time schedulerPOSIX-like interface to device driversReal-Time FIFOs Shared memory buffersPOSIX-like IPCBlocking mutexesSemaphoresSource-level debugger supportSerial port interfaceRTLinux: Microkernel DetailsSchedulerPreemptive, priority basedHardware context switch is not usedReason: saves too much state, not fast enoughStack is used insteadRT kernel handles hardware interruptsLinux thread does not directly receive themWhen Linux wants to disable interruptsThe microkernel stops passing them to the Linux threadHowever, real-time tasks can receive themRTLinux: Real-Time TasksRT kernel modulesTake advantage of microkernel’s RT APICan provide a device-like interface (RTFIFO) for non real-time tasksCan share devices with non real-time tasks RT tasks always get serviced firstExample: Dual Data AcquisitionPicture from www.embedded.com website.RTLinux vs. RTAIRTAI is based on RTLinuxHowever, design philosophy differsRTAI: Focused on adding new featuresEasier to useCaveat: performance hitRTLinux: RTOS must be very fastAny additional functionality must be optionalMicrokernel must remain “micro”Platform supportRTLinux: x86, Alpha, PPC, Linux v. 1.3-2.4RTAI: x86, Linux v. 2.2Priority Inversion and RTLinuxUnlike most RTOS’s RTLinux does not attempt to solve the priority inversion problem.“I think that priority inheritance is for people who want to build complex critical real-time systems that sometimes work.”, Victor Yodaiken, RTLinux author. Author suggests: “… use well known, time-tested methods such as flip buffers and message queues (or RTfifos).”Another proposed solution is to disable microkernel thread switching while semaphores are heldThis approach is similar to priority ceiling However: System will give up multitasking capabilities inside critical sections.ReferencesuClinux Home page, http://www.uclinux.orgSRT-Linux Home page, http://www.uk.research.att.com/~dmi/linux-srt/QLinux Home page, http://www.cs.umass.edu/~lass/software/qlinux/Ivchenko, A. “Real-Time Linux”, Embedded System Programming, May 2001RTLinux Home page, http://www.rtlinux.orgRTLinux FAQ, http://www.rtlinux.org/documents/faq.html“RTLinux: An interview with Victor Yodaiken”, http://www.acm.org/crossroads/xrds6-1/yodaiken.htmlRTAI, http://opensource.lineo.com/rtai.htmlSha, L.; Rajkumar, R.; Lehoczky, J.P. Priority inheritance protocols: an approach to real-time synchronization. IEEE Transactions on Computers, vol.39, (no.9), Sept. 1990. p.1175-85.