Ada & Embedded/Real Time Linux Ted Baker Dept of Computer - - PowerPoint PPT Presentation

ada embedded real time linux
SMART_READER_LITE
LIVE PREVIEW

Ada & Embedded/Real Time Linux Ted Baker Dept of Computer - - PowerPoint PPT Presentation

Ada & Embedded/Real Time Linux Ted Baker Dept of Computer Science Florida State University Tallahassee, FL 32306-4530 USA baker@cs.fsu.edu http://www.cs.fsu.edu/~baker SIGAda 14 November 2000 1 Acknowledgements Hongfeng Shen


slide-1
SLIDE 1

1

Ada & Embedded/Real Time Linux

Ted Baker Dept of Computer Science Florida State University Tallahassee, FL 32306-4530 USA baker@cs.fsu.edu http://www.cs.fsu.edu/~baker SIGAda 14 November 2000

slide-2
SLIDE 2

2

Acknowledgements

  • Hongfeng Shen – RT Linux V1 GNULLI
  • Arnaud Charlet – GNAT & GNARL

integration, testing, optimizations

  • Mike Kamrad & Top Layer Networks –

GNARL pruning

slide-3
SLIDE 3

3

Outline

  • Motivation: embedded Ada and OS needs
  • RT Linux
  • A GNAT runtime system for RT Linux
  • More Recent Developments
  • Future Prospects
  • Maybe some comments on patents*
slide-4
SLIDE 4

4

Motivation

  • Ada tasking was intended to be

implementable on a bare machine

  • Ada 95 improved the fit
  • Ravenscar profile went further
  • Operating systems still limit performance
  • Need “free” real-time Ada platform
  • Research and instructional tool
slide-5
SLIDE 5

5

Ada 95 Rationale Tasking Model

  • Strictly preemptive scheduling
  • Queueless locks
  • Only ready tasks can hold locks
  • Require locker active priority > lock ceiling
  • Lock holder inherits ceiling of lock
  • Lock operation raises active prio. to ceiling
  • Unlock restores previous prio. & schedules
slide-6
SLIDE 6

6

GNARL Architecture

Ada application program GNARL Threads Layer GNULLI GNULLI GNARL Ada application program Operating System Machine Machine

Middle layers can be removed.

slide-7
SLIDE 7

7

The Real-Time OS Problem

  • MS Windows & full Unix systems not

suitable for hard real time applications

  • Cannot be retro-fitted

– Too large – Too complex – Too unreliable

  • Specialized RT OS’s exist…but which one?
slide-8
SLIDE 8

8

Real-Time OS Woes

  • Not standardized, despite POSIX efforts
  • Proliferation of products, versions, features:

Which one(s) should Ada runtime support?

  • Conflict of demand for large-OS features vs.

predictability, reliability, small footprint

  • Advanced real-time ideas not being

supported quickly enough

  • Closed source code
slide-9
SLIDE 9

9

Build a New RT OS?

  • OS very costly to develop, maintain
  • Device drivers are especially costly

– Poor documentation of device interfaces – Debugging difficulty – Plethora of devices need to be covered

  • Multiple hardware platforms
  • Patents* may restrict new entries
  • Who can catch up with big vendors?
slide-10
SLIDE 10

10

A Solution

  • Layer real-time OS beneath existing OS
  • Provide virtual machine for background OS
  • Run real-time tasks in foreground
  • Provide data and control connections

between foreground and background

slide-11
SLIDE 11

11

Benefits

  • Predictable hard-real-time performance
  • Complex non-real-time functions can be

performed in the background OS

  • Background OS is intact
  • Background OS device drivers inherited for

uses without hard real-time constraints

slide-12
SLIDE 12

12

An early layered kernel: TARTE

  • Ada real-time kernel beneath DOS
  • DOS runs as background task
  • Supports Ada 98 “featherweight tasks”
  • Predictable timing, low overhead
  • FSU developed for STARS Foundations,

delivered in 1988

slide-13
SLIDE 13

13

1996 Plan at FSU

  • Apply TARTE idea to Ada 95
  • Build tasking kernel to run directly on

hardware

  • Run DOS or Windows 95 in background
slide-14
SLIDE 14

14

Then came RT Linux …

slide-15
SLIDE 15

15

What is RT Linux?

  • Small real-time OS that lies under Linux,

the popular “free” Unix operating system

  • Supports threads inside the Linux kernel
slide-16
SLIDE 16

16

RT Linux™

  • Victor Yodaiken, et al.
  • New Mexico Institute of Technology
  • Trademark of FSMLabs

– www.rtlinux.com

  • Open-source software, under GPL

– www.rtlinux.org

  • For Linux kernels 1.0 – 2.4
  • For x86, PowerPC, Alpha
slide-17
SLIDE 17

17

RT Linux Features

  • Foreground real-time threads
  • Shared virtual address space with Linux
  • Postponed delivery of hardware interrupts
  • FIFO buffers between fore and background
  • Easily replaceable scheduler
  • Fine-grained clock and interval-timer
  • Implemented via Linux kernel modules
slide-18
SLIDE 18

18

RT Linux Model

Linux Process Linux Process Linux Process Linux Kernel RT Thread RT Thread RT Thread RT Scheduler Linux Scheduler RT Timers FIFO scheduling read/write scheduling

  • ther interrupts

Linux Handlers timer interrupt

slide-19
SLIDE 19

19

Linux Kernel Modules

  • OS extensibility mechanism
  • Dynamically loadable and unloadable
  • Run in kernel address space
  • init_module runs when module inserted
  • cleanup_module when module removed
slide-20
SLIDE 20

20

1997 Plan

  • Ada application : Linux kernel module
  • Port GNULLI to RT Linux
  • Test GNULLI directly, then integrate
  • Restrict GNARL as necessary
  • Modify GNAT to support kernel environ.

and optimize for restricted cases

slide-21
SLIDE 21

21

GNARL RT Linux Architecture

Ada application program GNARL Threads Layer GNULLI RT-Linux + GNULLI GNARL Ada application program Operating System Machine Machine

slide-22
SLIDE 22

22

Foreground & Background

Ada Runtime Ada Application Module Other Kernel Modules Linux OS Kernel Other Kernel Modules Other Kernel Modules FIFO Devices Devices Devices Ada Runtime Ada Application Program FIFO FIFO

slide-23
SLIDE 23

23

RT Linux GNULLI

  • Implemented in 1997-98
  • Based on RTLinux Version 1.0-1.2

(which supported only single CPU)

  • Discarded RTLinux scheduler
  • Kept interrupt hijacking, timer, FIFOs
slide-24
SLIDE 24

24

Simplifications

  • Single control block per task/thread
  • Pre-allocated control blocks
  • Pure ceiling locking, no lock queues
slide-25
SLIDE 25

25

Initial Challenges

  • No experience with kernel modules in Ada
  • Cannot use C header files directly
  • GNARL was more than wanted, intertwined
  • Need to execute before elaboration
  • Running in kernel imposed restrictions
slide-26
SLIDE 26

26

Kernel Restrictions

  • Memory is limited
  • Modules must be complete

– May only refer to symbols in kernel & previously loaded modules

  • Cannot make OS calls from inside kernel

– e.g., no malloc() or I/O – GNAT uses dynamic storage allocation

slide-27
SLIDE 27

27

GNULLI Performance (1999)

  • Harmonic task set: 320, 160, 80, 40, 20, 10 Hz
  • Pattern:

– lock; work; unlock; work; lock; work; unlock;

  • Work depends on load level parameter
  • Load level is adjusted, by bisection, until

maximum schedulable utilization is reached

  • 97% CPU utilization
  • n 90MHz/33MHz Pentium PC, one CPU
slide-28
SLIDE 28

28

GNULLI Lock-Unlock Performance

1.06 microseconds per cycle

  • n 90MHz/33MHz Pentium PC, one CPU
slide-29
SLIDE 29

29

Ada Tasking Performance

3.1 us 9.7 us 4.6 us

po ‘‘rendezvous’ ’

1.4 us 4.7 us 3.5 us

protected procedure

1.1 us 3.1 us 2.3 us

simple protected procedure

RT-Linux threads Linux threads FSU threads These figures are on 166MHz/66MHz Pentium PC

slide-30
SLIDE 30

30

What we Knew in 1999

  • Linux kernel modules can be written in Ada
  • Ada tasking supportable in the Linux kernel
  • Ravenscar restrictions are helpful, but

tighter than necessary

  • Timing predictability is as desired
  • Overhead is very low
slide-31
SLIDE 31

31

Where we Expected to go

  • Get RT Linux port into GNAT distributions
  • Improve ease of use
  • Further reduce runtime system size
  • Add further compiler optimizations
  • Add “standard” packages for FIFOs
  • Keep up with new versions of RT Linux
  • Experiment with sporadic scheduling, dynamic

loading, distributed systems annex partitioning

slide-32
SLIDE 32

32

Why we are not there

  • No funding for FSU Ada work
  • Changes to RT Linux
  • New technical issues related to SMP
  • Chairing a growing department

www.cs.fsu.edu

slide-33
SLIDE 33

33

Divergent RT Linux Evolution

  • Several RTLinux™ versions: 1, 2, 3
  • Several more spin-off variants, e.g.

– RTAI

  • www.aero.polimi.it/projects/rtai

– TimeSys Linux/RT ™

  • www.timesys.com

– Zentropix Realtime Linux

  • www.zentropix.co.uk
slide-34
SLIDE 34

34

RT Linux Versions

  • V1 – the one we targeted
  • V2 – the current “stable” version

– Starts to be like POSIX threads – Supports SMP

  • V3 – the development version

– Aims to be closer to POSIX

  • Conservative view about adding to API
  • Maybe converging
slide-35
SLIDE 35

35

What we are doing at FSU

  • Update to RT Linux Version 2
  • SMP support
  • Single and queue-per CPU models
  • Performance comparisons

– C RTLinux versus Ada – Single timer+ready queues versus per-CPU – Static versus dynamic queue

slide-36
SLIDE 36

36

New Technical Issues

  • New RT Linux API

– requires GNULLI recoding

  • SMP

– Breaks old GNULLI environment task mapping – Opens hard design choices – Generally adds complexity

slide-37
SLIDE 37

37

More Issues

  • How to recover from failures in kernel
  • Continuing order problems
  • Getting “self” depends on CPU

– Per-cpu data is all volatile – frequently accessed for spinlocks

slide-38
SLIDE 38

38

Conclusion

  • RT Linux V1 GNAT port seems to work,

and is in gnat.com baseline, but not in public releases

  • RT Linux a valuable platform for Ada
  • RT Linux V2 port is not ready yet
  • There are some questions left…
slide-39
SLIDE 39

39

THE END

slide-40
SLIDE 40

40

Questions

  • Should we revert to Pthreads?
  • Is RT Linux the final answer?
  • Should we worry about patents?
slide-41
SLIDE 41

41

Should we revert to Pthreads?

  • Some more overhead would be paid
  • RT Linux is moving that direction
  • Portability and upkeep would be reduced
  • Usual Gnu leverage
  • Yodaiken seems opposed to all priority

inversion fixes, including ceiling locking

  • Convince him?
slide-42
SLIDE 42

42

Is RT Linux the final answer?

  • Safety could be better
  • Linux kernel big, complicated, still there
  • Protect RT kernel against Linux kernel?

– Separate virtual address space

  • Protect RT kernel against threads?
  • Debugging support?
  • Patent may get in the way of improvements
slide-43
SLIDE 43

43

Yodaiken Patent

  • US Patent 5995745
  • Applied for Nov 1997
  • Granted Nov 1999
  • “Adding real-time support to general

purpose operating systems”

  • Liberal (free) licensing for Gnu software
slide-44
SLIDE 44

44

Opening the Patent Door Wider

  • The Yodaiken RTLinux patent is a peek at a

much bigger picture.

  • Check out www.uspto.gov/patft.
  • Try tracing back the references.
  • Many surprising and interesting patents

show up.

slide-45
SLIDE 45

45

US Patent 5469571

  • Lynx Real-Time Systems, Inc
  • Applied July 1991
  • Granted Nov 1995
  • “Operating system architecture using

multiple priority light weight kernel task based interrupt handling”

slide-46
SLIDE 46

46

US Patent 5515538

  • Sun Microsystems, Inc.
  • Applied March 1994
  • Granted May 1996
  • “Apparatus and method for interrupt

handling in a multi-threaded operating system kernel”

slide-47
SLIDE 47

47

US Patent 5247675

  • IBM
  • Applied Aug 1991
  • Granted Sep 1993
  • “Preemptive and non-preemptive

scheduling and execution of program threads in a multitasking operating system”

slide-48
SLIDE 48

48

Questions

  • Are these patents valid?
  • Was there prior art?
  • Are the ideas obvious?
  • How many more well-known or obvious

software ideas are patented or have patents pending?

  • Is it safe to write software any more?
slide-49
SLIDE 49

49

APPENDIX

slide-50
SLIDE 50

50

Kernel Module in C

#define MODULE #include <linux/module.h> int init_module (void) { printk (“Hello, World\n”); return 0;} void cleanup_module (void) { printk (“Goodby, World!\n”);}

slide-51
SLIDE 51

51

Ada Kernel Module

package Hello is type Aliased_String is array (Positive range <>)

  • f aliased Character;

pragma Convention (C, Aliased_String); Kernel_Version : constant Aliased_String := "2.0.33" & Character’Val (0); pragma Export (C, Kernel_Version, kernel_version"); Mod_Use_Count : Integer; pragma Export (C, Mod_Use_Count, "mod_use_count_"); procedure Printk (Message : String); pragma Import (C, Printk, "printk"); function Init_Module return Integer; pragma Export (C, Init_Module, "init_module"); procedure Cleanup_Module; pragma Export (C, Cleanup_Module, "cleanup_module"); end Hello;

slide-52
SLIDE 52

52

Ada Kernel Module (body)

package body Hello is procedure Hello_Elabb; pragma Import (Ada, Hello_Elabb, "hello___elabb"); function Init_Module return Integer is begin Hello_Elabb; Printk ("Hello, World!" & Character’Val(10)); return 0; end Init_Module; procedure Cleanup_Module is begin Printk ("Goodbye, World!" & Character’Val(10)); end Cleanup_Module; end Hello;

slide-53
SLIDE 53

53

GNULLI Operations

  • create/destroy task
  • lock/unlock
  • (timed) sleep/wakeup
slide-54
SLIDE 54

54

Lock Operation on Pthreads

procedure Write_Lock (L : access Lock; Ceiling_Violation : out Boolean) is Result : Interfaces.C.int; Begin Result := pthread_mutex_lock (L.L’Access); Ceiling_Violation := Result /= 0; end Write_Lock; (Assumes mutexes support ceiling locking, which they generally do not.)

slide-55
SLIDE 55

55

Bare Single-CPU Lock Operation

procedure Write_Lock (L : access Lock; Ceiling_Violation : out Boolean) is Prio : constant System.Any_Priority := Current_Task.LL.Active_Prio; begin … ceiling check omitted … L.Pre_Locking_Prio := Prio; Current_Task.LL.Active_Prio := L.Ceiling_Prio; if Current_Task.LL.Outer_Lock = null then Current_Task.LL.Outer_Lock := L.all'Unchecked_Access; end if; end Write_Lock;

slide-56
SLIDE 56

56

SMP Lock

  • Needs per-CPU data
  • Needs Spin_Lock
slide-57
SLIDE 57

57

Unlock Operation on Pthreads

procedure Unlock (L : access Lock) is Result : Interfaces.C.int; begin Result := pthread_mutex_unlock (L.L’Access); end Unlock;

slide-58
SLIDE 58

58

Bare Unlock Operation

procedure Unlock (L : access Lock) is Flags : Integer; begin if Current_Task.LL.Outer_Lock = L.all’Unchecked_Access then Current_Task.LL.Active_Priority := Current_Task.LL.Current_Priority; Current_Task.LL.Outer_Lock := null; else Current_Task.LL.Active_Priority := L.Pre_Locking_Priority; end if; if Current_Task.LL.Active_Priority < Current_Task.LL.Succ.LL.Active_Priority then Save_Flags (Flags); -- Saves interrupt mask Cli; -- Masks interrupts Delete_From_Ready_Queue(Current_Task); Insert_In_Ready_Queue (Current_Task); Restore_Flags (Flags); Call_Scheduler; end if; end Unlock;

slide-59
SLIDE 59

59

SMP Unlock

  • Needs CPU-specific data
  • Needs Spin_Unlock
  • Also needs spinlock to protect ready queue,

for priority-lowering

  • Needs IPI, with single-queue model
slide-60
SLIDE 60

60

Sleep on Pthreads

procedure Sleep (Self_ID : Task_ID; Reason : Task_States) is Result : Interfaces.C.int; Begin if Self_ID.Pending_Priority_Change then Self_ID.Pending_Priority_Change := False; Self_ID.Base_Priority := Self_ID.New_Base_Priority; Set_Priority (Self_ID, Self_ID.Base_Priority); end if; Result := pthread_cond_wait (Self_ID.LL.CV’Access, Self_ID.LL.L.L’Access); pragma Assert (Result = 0 or else Result = EINTR); end Sleep;

slide-61
SLIDE 61

61

Bare Sleep

procedure Sleep (Self_ID : Task_ID; Reason : System.Tasking.Task_States) is Flags : Integer; begin Self_ID.State := Reason Save_Flags (Flags); Cli; Delete_From_Ready_Queue (Self_ID); if Self_ID.LL.Outer_Lock = Self_ID.LL.L’Access then Self_ID.LL.Active_Prio := Self_ID.LL.Current_Prio; Self_ID.LL.Outer_Lock := null; else Self_ID.LL.Active_Prio := Self_ID.LL.L.Pre_Locking_Prio; end if; Restore_Flags (Flags); Call_Scheduler; Write_Lock (Self_ID); end Sleep;

slide-62
SLIDE 62

62

SMP Sleep

  • Needs Spin_Lock on ready queue
  • Needs Spin_Unlock on own lock
slide-63
SLIDE 63

63

Wakeup on Pthreads

procedure Wakeup (T : Task_ID; Reason : Task_States) is Result : Interfaces.C.int; Begin Result := pthread_cond_signal (T.LL.CV’Access); pragma Assert (Result = 0); end Wakeup;

slide-64
SLIDE 64

64

Bare Wakeup

procedure Wakeup (T : Task_ID; Reason : System.Tasking.Task_States) is Flags : Integer; begin T.State := Reason; Save_Flags (Flags); Cli; -- Disable interrupts. if Timer_Queue.LL.Succ = T then if T.LL.Succ = Timer_Queue then No_Timer; else Set_Timer (T.LL.Succ.LL.Resume_Time); end if; end if; Delete_From_Timer_Queue (T); Insert_In_Ready_Queue (T); Restore_Flags (Flags); Call_Scheduler; end Wakeup;

slide-65
SLIDE 65

65

SMP Wakeup

  • Needs Spin_Lock on ready queue
  • Needs IPI, with single-queue model
slide-66
SLIDE 66

66

Hidden Init/Cleanup_Module

pragma Suppress (All_Checks); package Demo is pragma Elaborate_Body; end Demo;

slide-67
SLIDE 67

67

Hidden Init/Cleanup Module

pragma Suppress (All_Checks); with System.OS_Interface; package body Demo is use System.OS_Interface; task T; task body T is begin Printk("Hello, World!” & ASCII.LF); end T; end Demo;

slide-68
SLIDE 68

68

Interval vs. Periodic Timer