Porting - Technical Challenges
What is Porting
The term porting is a general way to refer to the changing of software/hardware to make your application usable in different environments in most cases, is thought to be a better one. For eg., Run a software program from one operating system in which it was developed (Solaris) to another operating system (Linux) so that it can be used, Porting implies some degree of effort, but not nearly as much as redeveloping the program in the new environment.
When to do Porting
Software is portable when the cost of porting it to a new platform is much less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be.
Why to do porting?
We can do porting:
- To change code to adapt to hardware/software
- When there are differences in OS versions
- When there are missing OS functionalities
- Manage multiple code bases across different versions
- To leverage on the existing code rather than build and develop software from scratch
- To increase the customers’ level of software reuse in product development
- To protect software investment
- Shorten time to market
- To provide real-time performance
- When there is a discontinue use of obsolete APIs
- Process support in VxWorks 6.x but not in 5.x
- OS differences between 32 and 64 bit CPU
Technical Challenges in Porting
Porting is usually quicker and cheaper than performing a full code rewrite. However, manual porting can turn into a major code rewrite if the underlying OS platforms are very different. Ideally, If you can reuse your existing code without having to do any “porting“ at all, then it’s all the more better. Existing code works and has been perfected in the field. Throwing it away and starting from scratch because of a change in environments is not sensible.
- Porting is more effective and efficient if there is a lot of code.
- The code may compile on one compiler but not another.
- Code developed in a specific language may become obsolete (Ada, Fortran, etc.).
- Tools may not be available for new hardware platform. Development on host may not be possible.
- There may be a delay in start of development until the new target hardware/tools become available.
- Need to deal with target issues while porting. APIs proprietary is another issue to be concerned about.
- The APIs Code may get locked to a specific vendor’s OS platform.
- There may be industry standard variations, variations in API behavior, Level of API support and what is actually supported by OS vendors.
How to do Porting?
Abstraction plays a central role in software reuse. In order to avoid porting issues altogether, organizations see the need for an abstraction solution to protect their code against future platform changes. However, developing an abstraction interface using native OS APIs will not give the portability and performance needed in an embedded application. Instead, a lower level approach needs to be taken to ensure that the fundamental OS resources, such as threads, semaphores, mutex, etc., will behave the same across platforms and that performance is not impacted. Also, building and maintaining an in-house abstraction for multiple operating systems requires considerable time, money and resources. The developers must have detailed knowledge of each operating system and perform a lot of testing to verify portability across different platforms, which results in high costs. This is why many companies are turning towards a COTS ( Commercially off the shelf) abstraction layer which is maintained, tested and verified by an outside company, rather than taking focus away from the organization’s core competencies. The use of common APIs, provided by the COTS OS abstraction, across platforms also lessens any potential learning curve when developing with new operating systems, thereby making code reuse easier to adopt.
To accommodate future needs and avoid such an intricate project, developers need a COTS OS abstraction to make developing portable software effortless.
The abstraction needs to allow for design alterations without requiring a software rewrite, thus protecting the software investment. This abstraction tool should be engineered with safety critical features vital to defense and mission systems, without sacrificing real-time performance.
To know more about OS Abstractor product, check this out: http://mapusoft.com/admin/wp-content/uploads/OSAbstractor.overview.pdf