OpenSAF Porting by Vikrant Gogri Sr. Project Manager

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 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 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 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 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 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 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 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 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 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 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 Questions??? ?????????

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