ELCEurope 2009 Grenoble · Common porting strategies ... – Over ad hoc API Kernel space User...
Transcript of ELCEurope 2009 Grenoble · Common porting strategies ... – Over ad hoc API Kernel space User...
-
Philippe GERUM - SourceTrek
ELCEurope 2009 Grenoble
-
Introduction
-
The context
● Linux about to be natively real-time– PREEMPT_RT close to mainline
-
The context
● Linux about to be natively real-time– PREEMPT_RT close to mainline
● Legacy applications knocking on Linux's door– Traditional, embedded RTOS– Non-POSIX core API– Flat / physically addressed memory– Typically: VxWorks, pSOS, VRTX etc.
-
The issue
● Porting them to Linux currently means– Rebasing on Linux, changing design
or,– Keeping design, keeping proprietary RTOS
● How to go the Linux way?– Keeping design, using Linux technologies
-
Possible solution
● Combine existing Linux technologies– Native real-time support– Linux-native virtualization– RTOS emulation
-
Common porting strategies
● Port to dual kernel– Over POSIX API– Over API emulator– Over ad hoc API
Kernel space
User space
Real-time core
Application
APIs, emulators
Linuxsub-systems
RT driversRT drivers
Regulardrivers
Regulardrivers
RT libraries GNU libc
-
Common porting strategies
● Go Linux native– Over POSIX API– Over API emulator
Kernel space
User space
Application
Linuxsub-systems
RT driversRT drivers Regular
drivers
Regulardrivers
GNU libc
EmulatorsEmulators
-
Common porting strategies
● Introduce virtualization– Original RTOS guest– Vendor-specific
● Bare metal hypervisor– Leverage multi-core
Bare metal (RT) HypervisorBare metal (RT) Hypervisor
Linu
x
RTO
S
SBC
/ ha
rdw
are
Core Core
-
Approaches are challenging
● Dual kernel Linux architecture is complex
-
Approaches are challenging
● Dual kernel Linux architecture is complex
LibrariesLibraries
Rea
l-tim
e st
ack
Reg
ular
Lin
ux
Drivers
Core Core
Drivers
Libraries
Apps Apps
-
Approaches are challenging
● Dual kernel Linux architecture is complex– Pressure on application design
LibrariesLibraries
Rea
l-tim
e st
ack
Reg
ular
Lin
ux
Drivers
Core Core
Drivers
Libraries
Apps Apps
-
Approaches are challenging
● Native real-time Linux is complex
-
Approaches are challenging
● Native real-time Linux is complex
LibrariesLibraries
Drivers
Core
Apps
Global efficiency
General fairness
Bounded latency
Total unfairness
RegularReal-time
-
Approaches are challenging
● Native real-time Linux is complex– Pressure on system configuration
LibrariesLibraries
Drivers
Core
Apps
Global efficiency
General fairness
Bounded latency
Total unfairness
RegularReal-time
-
Approaches are challenging
● Proprietary virtualization systems?
-
Approaches are challenging
● Proprietary virtualization systems?– Introduce dependencies on vendor
● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest
-
Approaches are challenging
● Proprietary virtualization systems?– Introduce dependencies on vendor
● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest
– Enable Linux for proprietary RTOS
-
Approaches are challenging
● Proprietary virtualization systems?– Introduce dependencies on vendor
● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest
– Enable Linux for proprietary RTOS
BUT,– Do not help the Linux real-time effort
-
Teams are challenged
● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls
-
Teams are challenged
● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls
● Driver model– Weak vs strong– Linux kernel API is more complex
-
Teams are challenged
● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls
● Driver model– Weak vs strong– Linux kernel API is more complex
● Protocol stacks– Keep “as is” or offload to Linux?
-
Legacy issues
● Software architecture– BSP code exposed– Application and driver code entangled– Non-public API sometimes used
-
Legacy issues
● Software architecture– BSP code exposed– Application and driver code entangled– Non-public API sometimes used
● Programming model– Flat / physically addressed memory assumed– Supervisor mode assumed– CPU architecture assumed
-
About RTOS emulators
-
RTOS API emulation?
● A way to mimic the RTOS interfaces– Evades the BSP issue– Source-level approach
● Has real-time requirements– Must run over a deterministic core– Must exhibit real-time properties itself
-
Myths and Reality
● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set
-
Myths and Reality
● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set
Do you trust your vendor documentation?
-
Myths and Reality
● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set
Do you trust your vendor documentation? YES
Should your code rely on undocumented features?
-
Myths and Reality
● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set
Do you trust your vendor documentation? YES
Should your code rely on undocumented features? NO
Should your code expect undocumented behavior?
-
Myths and Reality
● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set
Do you trust your vendor documentation? YES
Should your code rely on undocumented features? NO
Should your code expect undocumented behavior? NO
Therefore, you don't need the original API implementation to emulate it properly.
-
Myths and Reality
● Isn't API emulation slower?
-
Myths and Reality
● Isn't API emulation slower?– Traditional RTOS share basic semantics
● Optimized building blocks can be made● Efficient “window-dressing” follows● Leveraging single address space helps
-
Myths and Reality
● Isn't API emulation slower?– Traditional RTOS share basic semantics
● Optimized building blocks can be made● Efficient “window-dressing” follows● Leveraging single address space helps
– Naive emulation over POSIX not enough● POSIX semantics do not map 1:1● POSIX-based building blocks may work better
-
RTOS emulators shortcomings
● Limited emulation coverage– noarch/generic core services
-
RTOS emulators shortcomings
● Limited emulation coverage– noarch/generic core services
● Require Application / Driver split– BSP code not accessible from user-space– I/O resources live in kernel space
-
RTOS emulators shortcomings
● Limited emulation coverage– noarch/generic core services
● Require Application / Driver split– BSP code not accessible from user-space– I/O resources live in kernel space
● Restricted by Linux protections– No supervisor actions from user-space
-
Our assets
-
PREEMPT-RT
● Fully native real-time support– Enables real-time virtualization
● Promise of embedded multi-core scalability– Sophisticated locking model– Sophisticated scheduling
-
KVM
● Complete sandboxing● Compatible memory spaces● Device virtualization through host
– virtio● Device emulation through VM
– Qemu-based modelling
-
Introducing Xenomai
● Generic RTOS core● Host abstraction
– Dual kernel– Simulator– (Single image *)
Generic RTOS
SAL
Host system (Linux, Simulator)
(*) Xenomai/SOLO
-
Introducing Xenomai
● Generic RTOS core● Host abstraction
– Dual kernel– Simulator– (Single image *)
● RTOS personalities
VxWorks pSOS VRTX ...
Generic RTOS
SAL
Host system (Linux, Simulator)
(*) Xenomai/SOLO
-
Introducing Xenomai
● RTOS building blocks– Thread scheduling– Synchronization– Interrupt handling– Memory allocation– Timing services Bu
ildin
g bl
ocks
Sched
Synch
IRQ
Memory
Timing
-
Introducing Xenomai
● RTOS building blocks– Thread scheduling– Synchronization– Interrupt handling– Memory allocation– Timing services Bu
ildin
g bl
ocks
e.g.
VxW
orks
taskLib
semLib
msgQLib
wdLib
tickLib
sysLib
Sched
Synch
IRQ
Memory
Timing
-
What about combining?
● Real-time host kernel– PREEMPT-RT
Real-time kernel sub-systems
Real-timeApplication
-
What about combining?
● Real-time host kernel– PREEMPT-RT
● Virtualization core– KVM– QEMU
KVM
Guest
QEMU
-
What about combining?
● Real-time host kernel– PREEMPT-RT
● Virtualization core– KVM– QEMU
● RTOS emulation– Xenomai
KVM
Xenomaiemulator
QEMU
-
Virtualization + RTOS emulation
Improvements● Native real-time● Original programming model● Better emulation coverage● Sandboxing● Legacy device emulation
-
Virtualization + RTOS emulation
Restrictions● No ABI compatibility● Still not 100% source compatible● Reworking the device driver layer still required
-
Virtualize & Emulate
-
Improved emulation engine
Emulation core● Xenomai guest
– Freestanding mode– RTOS personality
● QEMU– Virtual machine
Emulator
Xenomai
QEMU
Application
-
Improved emulation engine
Handling I/O● Paravirtualized
– Common hw– High bandwidth
● Emulated– Precise emulation– Low bandwidth
Emulator
Xenomai
QEMU
PV
Drivers
EMU
virt
io
Application
-
Improved emulation engine
Native real-time VMM● PREEMPT-RT host
– KVM-enabled
Linux -rt
Emulator
Xenomai
QEMU
PV
KVM
Drivers
EMU
virt
io
Application
-
TODO list
● Real-time aware KVM– Guest scheduling
● Real-time aware QEMU– I/O emulation
● Guest mode Xenomai core● Extended emulation coverage
-
More applications
-
Could also be used for...
● Application-specific virtual RTOS– Virtual RT appliance (sort of)
-
Could also be used for...
● Application-specific virtual RTOS– Virtual RT appliance (sort of)
● Transition path for in-house RTOS– Consolidate & extend via virtualization
-
Could also be used for...
● Application-specific virtual RTOS– Virtual RT appliance (sort of)
● Transition path for in-house RTOS– Consolidate & extend via virtualization
● Simulation of complex architectures– e.g. modeling Arinc653 systems
-
Conclusion
-
Legacy RT application to Linux
Today● Rebase on Linux, change design● Keep design, keep proprietary RTOS
-
●Legacy RT application to Linux
Today● Rebase on Linux, change design● Keep design, keep proprietary RTOS
Tomorrow● Combine existing technologies
– Rely on real-time capable virtualization– Couple with accurate RTOS emulation
-
●The End
Thank you for attending
Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 49Slide 50Slide 51Slide 52Slide 53Slide 54Slide 55Slide 56Slide 57Slide 58Slide 59Slide 60Slide 61Slide 62