Challenges in Porting & Abstraction

Getting Locked-In Applications are developed with a particular platform in mind The software is locked to the current platform If a component of that platform changes, the application will no longer run without costly changes to the code due to variances in platforms Reasons platforms change Changes in technical requirements Switching to more economical platforms Platform becomes obsolete Market & industry demands

Lots of time and money go into developing an application This investment must be protected when platforms change Developers need to leverage their existing software to re-coup the time and money Software reuse can be accomplished two ways: Porting existing code to a new platform Using an abstraction platform for new code development Challenges are brought about by variances in platforms Advantages of Software Reuse

OS Model & Type Variations Single address (with or without MMU) Virtual address (User/Kernel mode, Process model) Single or multi-core (SMP/Async) 16/32/64 bit architecture Real-time (RTOS) or non real-time Safety-critical, Security certifications (Do178B, ARINC653, etc.) OS Simulator (OS emulations on x86 host platform) OS to application bindings (direct access, message based, etc.) OS based on virtualization (emulator, hypervisor, etc.) API proprietary or standards based, such as POSIX, uITRON, etc. Variations in OS Platforms

OS Process API Variations Real-time vs. non real-time Process creation (spawn, exec, fork, etc.) Inter-process communication (signals, messaging, pipes, etc.) Shared memory (data protection) OS Task API Variations Scheduling models (priority based, time-slice, etc.) Priority levels & ranges Task stack variations Critical region protection Variations in OS Platforms

OS Messaging API Variations Fixed/Variable message queues Sending message (fixed vs. unlimited) OS Mutex API Variations Shared vs. use within a process Deadlock prevention (priority in-heritance, ceiling, etc.) Performance impact Variations in OS Platforms

OS I/O System API Variations Proprietary vs. UNIX/ANSI model Offers levels of I/O control functions (ioctl) Device driver model variations (Linux vs. Windows drivers) OS Semaphore API Variations Binary vs. counting semaphores Usage within & across processes Dispatch order (FIFO, LIFO, Priority) Suspension (Polling vs. true) Variations in OS Platforms

OS Memory API Variations Fixed vs. variable allocation Virtual, physical or shared Defrag algorithm Alignment issues(architecture dependency) OS Clock & Timer API Variations Hardware Clock (timer interrupts per second) System Tick (interrupts per tick) Timer resolution Sleep & other application waits Variations in OS Platforms

What is Porting? Porting is the ability to reuse software from one environment to another by making minimal changes to the existing code Porting can turn into a major code-rewrite if the underlying OS platforms are very different This is a tedious and error prone task

Importance of Porting Porting is usually quicker and cheaper than performing a full code rewrite Existing code already works and has been perfected in the field Throwing it away and starting from scratch because of a change in environments is not sensible A porting tool can greatly decrease the amount of manual work involved

Challenges in Porting Differences in OS APIs Missing OS functionalities Obsolete APIs Managing multiple code bases across different OS versions Misleading POSIX portability

What is Abstraction? Abstraction provides the ability to develop software that can be re- used across multiple environments without changing the code A good abstraction protects software investment Keeps it from being locked-to a particular platform from day one

Importance of Abstraction Negates future porting issues and protects the code Avoids shifting the focus from the organization’s core competencies Ensures that the fundamental OS resources behave the same across all platforms Reduces potential learning curve and makes the concept of code reuse easier to adopt

Importance of Abstraction Allows for development of host based proof-of-concept application quickly Product development knowledge is not locked to a specific vendor’s tools, IDE or platform Hardware changes won’t impact applications Application development team can keep developing without worrying about changes to the hardware or underlying platform

Challenges in Abstraction Has to support a variety of operating systems and account for new versions in the future Should not impact the application’s performance Should not fully rely on the underlying OS

Abstraction Model Components Portability Support for a wide variety of OS, able to account for variances Able to support a new OS quickly API compliance at behavior level, not just interface level Performance Resource pooling API profiling & optimization Just-In-Time Virtualization of OS Models

Abstraction Model Components Stability & Robustness Mission critical features OS hardening Development Flexibility Simple, intuitive and thread-safe APIs Multiple API use within a single application Scalability within a component API usage across process, user-mode or kernel-mode

Questions? Contact MapuSoft MAPUSOFT Q & A