1. OpenSAF Porting by Vikrant Gogri Sr. Project Manager

2. 2 Introduction ➔ This presentation shall cover …. ➔ Porting experience of OpenSAF 2.0 from Linux to OpenSolaris. ➔ Challenges the team ran into while porting. ➔ Assumptions team made during the porting projects. ➔ Discovering the different issues involved in poring OpenSAF code to another operating systems.

3. 3 Background ➔ Sun Microsystems sponsored the porting for OpenSAF 2.0 to Solaris 10. ➔ Sun approached CalSoft, a software development and QA partner working with multiple groups at Sun, to do the port and contribute it back to the community ➔ CalSoft’s software engineering team to provide the ported code in timely manner. ➔ This was very aggressively time bound project as some of the Sun’s Customers wanted to use OpenSAF applications on Sun’s hardware running Solaris 10 Update 5 and be in the market with the ported platform.

4. 4 About Calsoft ➔ We are an Offshore Product Development services organization focused on developing software for clients who produce infrastructure products. ➔ Calsoft has been in business 10 years, profitable for all 10 years, and has 250 system software engineers with most of the talent located offshore in Pune (near Bombay/Mumbai), India. ➔ Calsoft has a proven track record in all phases of product development: Design, Development, Testing, (Test) Automation, and Sustaining ➔ Our client list includes large companies such as NetApp, Sun, VMware, HP, Brocade, a host of medium size companies such as Pillar Data, BlueArc, Panasas, and several start ups. ➔ Open source friendly organization-have made significant contributions into Linux2.6 kernel.

5. 5 Calsoft’s Capabilities ➔ Operating Systems  Linux,Solaris, FreeBSD, Windows, VxWorks, MontaVista, Mac, HP-UX, AIX  Operating system components like file systems, NFS, CIFS, drivers etc. ➔ Storage  Storage Management, Storage Network(SAN,NAS),Device drivers. ➔ Virtualization  Entire VMware product suite, Xen, HyperV, KVM. ➔ Networking/Telecom  TCP/IP,TOE, GSM, GSM AT command stacks, ISDN, ATM, PRS/EDGE, VOIP,Mobile operating systems and platforms. ➔ QA-Automation and Testing  Manual QA, Test harness and regression suite dev, Interop testing, Scalability testing.

6. 6 OpenSAF porting Project ➔ 1 st sucessful porting of OpenSAF to non-Linux OS. ➔ OpenSAF 2.0 porting to Solaris had following methodology:  Bring up the Linux cluster –controller and payload – as a reference platform. Run Sample Tests and Test Suite provided by the community to understand the reference for testing effort.  1 st Port the code to Solaris running on x86 systems and Gnu Compiler.  Port the code to Solaris running on Sparc systems and Gnu Compiler.  Port the code to Solaris running on x86 systems and SunStudio.  Port the code to Solaris running on Sparc systems and SunStudio.  Ensure the changes still works on Linux cluster. ➔ Project took about 4 Calendar Months. ➔ Efforts required: 16 Developers Man Months and about 10 QA Man Months.

7. 7 Bringing up Linux as a reference platform. ➔ Bringing up reference Linux Cluster required steep learning curve. ➔ SAForum specs and OpenSAF documentation like Install Guide, README helped quite a bit. ➔ But very little trouble shooting documentation. Resulting in 2 weeks to get the Linux cluster running. ➔ Running existing test suites and test sample took even longer than initially thought. This was primarily due to difficulties in triaging when things did not go right. ➔ Having troubleshooting documentation would have helped.

8. 8 Challenges in porting ➔ Overall relatively easy port, if one knows what and where to look for trouble spots. ➔ In C code, Leap layers made it quite easier, but exceptions to OS calls outside of Leap layers created challenges. Have to fall back to adding #ifdef in the code. ➔ Team had to keep looking for similar violating code traces in entire code bases. ➔ E.g. system(….) calling OS specific commands. ➔ E.g. expecting OS specific “/proc/…” files in code implementation.

9. 9 Challenges in porting … cont’d ➔ Besides C code, major effort was required in solving the platform dependent challenges in other areas as well. ➔ Some of them are:  Code Packaging – very OS specific e.g. RPM vs. pkgadm  Install scripts - Platform related assumptions caused install scripts issues e.g. assumption about the install path and issues with module install like modprobe on Solaris vs. insmod in Linux.  Run scripts to start and stop cluster services e.g. usage of killall

10. 10 OpenSAF ➔ OS dependent calls are indirect via LEAP library for most parts. This makes it quite portable. ➔ Challenges are when there are:  Direct OS dependent calls  semantic differences in the OS calls e.g. signal handlers  assumptions about OS File Systems e.g. /shm/ for shared memory interface. ➔ To overcome these, team had to do global search of various kinds to look for patterns that caused the troubles. ➔ Once identified, we had to come up with a fix like a generic code that will either work across all the paltforms or code using platform dependent #ifdefs.

11. 11 Some Suggestions ➔ OpenSAF has been designed with portability in mind. As a result Leap layer and efforts for POSIX compliance exist. But no piece of code is proven to be portable until ported to two or more Operating Systems. ➔ Also LEAP layer is not enough by itself. ➔ Services should limit system related code to standard LEAP interfaces. ➔ Even the install and run scripts should be as much as POSIX compliant.

12. 12 Summary ➔ Calsoft, in executing the OpenSAF porting project, has learnt great deal about the OpenSAF code base. ➔ Along the way, Calsoft team working on OpenSAF porting discovered quite a few challenges and found a way to overcome them. ➔ Calsoft believe its going to be a sure shot commercial success and Calsoft would like to play an active part in its success.

13. 13 Questions??? ?????????

14. 14 Thank You! CalSoft Pvt. Ltd. www.calsoftinc.com (iDeate. Design. Develop. Deploy)