Print-friendly Version

ISV Adoption Strategy for the Solaris 10 Operating System

Frederick Rehhausser and Chien Yen, March, 2005

Contents:

• Why the Solaris 10 OS?
• Prepare for Adoption
• Solaris Compatibility Assurance Toolkit (SolCAT)
• New Features in the Solaris 10 OS
• API Enhancements in the Solaris 10 OS
• The Solaris 10 OS on x86 Platforms
• Using Sun Studio Software for the Solaris 10 OS
• Resources Available for ISV Adoption Projects

Today, independent software vendors (ISVs) face a larger number of operating systems and products to support as well as the ever-increasing complexity of each of the supported products. With this competition for ISV attention and resources, the Solaris 10 Operating System (OS) needs to be compelling in terms of business issues and revenue gains, cost of the port and ongoing support costs, and feature benefits for the ISVs and their customers.

An effective adoption strategy for the Solaris 10 OS is critical to the ISV. Such a strategy can accelerate ISV cycle time to allow timely support for the Solaris 10 OS. Using this type of adoption strategy can provide both lower incurred costs and faster time-to-revenue for the ISV that adopts the latest Solaris release. ISVs need to be able to move aggressively but prudently to new releases of Solaris -- allowing them to take advantage of new features and powerful new systems without breaking their existing applications.

The Solaris 10 OS represents a major step in the evolution of enterprise-class operating systems, making major improvements from horizontally scalable small systems to vertically scalable data center-class systems. This article supplies specific information to help ISVs move their applications to the Solaris 10 OS from earlier releases and identify potential issues. Advice is provided to help qualify applications as well as integrate applications with the more advanced features of the Solaris 10 OS.

This article also provides an overview of the important new features in the Solaris 10 OS, with a focus on differences important to ISVs that may affect their applications.

A complete overview of Solaris 10 OS can be found in the white paper In a Class By Itself -- The Solaris 10 Operating System (pdf).

Why the Solaris 10 OS?

The Solaris 10 OS defines what the next-generation OS should be. Building on 20 years of experience, the Solaris 10 OS addresses the key customer concerns of cost, availability, and security, with new and innovative features that can set the standard for the industry. With the ability to scale up and scale out, the Solaris OS allows customers to use a common OS from the desktop to small systems to massive SunPlex clusters with hundreds of CPUs.

The Solaris 10 OS is considered the premier OS for the boundary-less data center, providing customers with a secure, cost-effective and highly available environment by design. Potential benefits include the following:

Solving critical customer needs (using technology to generate cost-effective solutions)

• Costs -- Providing lower costs of acquisition and total cost of ownership for ISVs and their customers through server consolidation, ease of adoption, higher availability, simpler system administration, and increased performance, through the use of Solaris Containers, Predictive Self Healing, improved network performance, system kernel tuning, Dynamic Tracing (DTrace), and Solaris Compatibility Assurance Toolkit (SolCAT) tools.
• Security -- Offering high-grade security for commercial systems in authentication and access rights management, as well as introducing process rights management.
• Availability -- With Predictive Self Healing, using a breakthrough approach to service availability and fault management.

Value to the ISV (monetize investments in the Solaris 10 OS)

• Making your applications more valuable -- Using the new features and interfaces in the Solaris 10 OS to quickly and easily add unique value to your solutions and make them stand out as superior in areas that customers care about.
• Giving you a competitive edge -- Accelerated application throughput, higher application and system availability, and process rights in the Solaris OS for application-level security.
• New revenue opportunities -- Expanding your market share by running your 64-bit applications on Sun's latest systems with AMD64 and Ultra-SPARC IV architectures.

Extending platform reach (not limited to a single platform)

• Platforms of choice for offerings based on UltraSPARC and AMD64 architectures. Among the industry's most comprehensive choice of AMD64 platforms with one-, two-, and four-way servers.
• Chip-Multithreading (CMT) -- Providing 64-bit solutions that range from small one-, two-, and four-way x86 or AMD64 systems to enterprise-class UltraSPARC systems capable of running 144 simultaneous threads.
• Linux interoperability with Linux compatibility tools and support, including Linux application binary interface (ABI) compatibility.

Protecting customers' and ISVs' investments (get running on the Solaris 10 OS quickly)

• Ensuring compatibility with SolCAT tools. Tools can help you ensure Solaris ABI compatibility when you develop your application, as well as testing your application for conformance to Solaris ABI interfaces. The result is that if your application runs on Solaris 8 and Solaris 9 releases, it will also run on the Solaris 10 OS.

Maintaining industry leadership (creating competitive advantage through technology)

• Thought leader: Continued innovation with Sun Java Enterprise System, Sun Java Desktop System, and Solaris OS breakthrough features, such as Predictive Self-Healing, Solaris Containers, WAN Boot, DTrace, and more.
• Performance and scalability leader: Scaling up on enterprise systems with optimal multi-threading CMT performance, highly efficient system utilization, and new service levels shielded from CPU and memory failures.
• Scaling out with wire-speed gigabit network performance, with highly tuned kernel performance, the choice of latest low-cost, high-volume AMD64 platforms, and Solaris Containers, available starting with the smallest one-way systems.

Prepare for Adoption

Providing a Smooth Upgrade to the Solaris 10 OS

Any operating system upgrade requires careful planning on the part of the ISV. Once an ISV has committed to support for the Solaris 10 OS, the ISV must develop an adoption plan. This plan for adoption of the Solaris 10 OS helps the ISV to:

• Decide on an adoption strategy.
• Decide on a testing strategy.
• Set up an adoption environment.

These tasks are constrained by the resources available for adoption, business justification, and compliance of an existing application with the Solaris ABI. An effective approach will accelerate adoption cycle time with lower costs and faster time to market.

Strategies for Solaris 10 OS Adoption

The Solaris 10 Operating System Adoption Kit (available on the iForce Partner partner web site) was designed to provide you with a comprehensive guide on how to incorporate the latest features and enhancements from the Solaris 10 OS into your applications. Also provided are documentation and resources for application testing, porting, and development. The kit offers two complementary strategies your company can take toward adoption: Fast Track and Advantage Track.

Fast Track to Solaris 10 OS

The quick and easy way to move your applications to the Solaris 10 OS. There is no need to recompile your applications. Upon general release of the Solaris 10 OS, Sun assures binary compatibility with previous releases of Solaris. This means that if your application is written to the Solaris Application Binary Interface, it will run without modification on the Solaris 10 OS.

Test your application for binary compatibility with the Solaris Application Scanner Tool. This process should be quick and easy. It can help you to identify any missing interfaces or other issues. If your application passes, install it on the Solaris 10 OS, and run your usual application acceptance test. Details on running SolCAT tools are given in the section called "Solaris Compatibility Assurance Toolkit (SolCAT)".

Figure 1 shows the Fast Track path to Solaris 10 OS adoption.

Figure 1: Fast Track Path to Solaris 10 OS Adoption

Finally, let us know that your application checks out! We'd like to count you as a Solaris 10 OS Early Adopter. Send an email to solaris-adoption@sun.com.

Advantage Track to Solaris 10 OS

The Advantage Track: Extending your applications with Solaris 10 OS new features. Take advantage of the breakthrough technologies in the Solaris 10 OS and make your applications more reliable, secure, and available.

Many of the new features in the Solaris OS are transparent to the application and require no modification on your part. Certain features need application inputs, application knowledge of system configuration, or system dependency checks.

Figure 2 shows the Advantage Track path to Solaris 10 OS adoption.

Figure 2: Advantage Track Path to Solaris 10 OS Adoption

With this two-pronged adoption strategy, the ISV has the opportunity to make a fundamental change in the support model for the Solaris 10 OS. With the Fast Track model, the ISV can immediately test and qualify the current family of applications on the Solaris 10 OS and declare support, profiting from the initial momentum of the Solaris 10 OS in the market with early adopters and other customers eager to use the advanced features and superior performance of this release.

ISVs can then fold the pertinent new features of the Solaris 10 OS into their application being readied for release, and on their schedule, do a full support and recompile, and qualify their latest application for the advanced features of the Solaris 10 OS and gain full competitive advantage for their applications.

Get adoption support from Sun, and tell us how we can help you! Support details are on the Solaris 10 Early Adoption web site. Let us know that you've adopted the new features. Send an email to solaris-adoption@sun.com.

Testing Strategy

Testing Your Applications for Solaris 10 ABI Compatibility on the Current OS Release

Like previous releases, the Solaris 10 OS supports the Solaris ABI for both SPARC and x86 architectures. Adherence to the Solaris ABI provides a binary compatible environment between releases and avoids potential problems -- for example:

• Applications that access private or undocumented interfaces may break when those interfaces change between releases.
• Applications that access system files directly rather than using the corresponding library functions can break if those database files change or are obsolete with a new release.
• Applications that are statically linked can break because the statically linked libraries they include are obsoleted with a new release. (The Solaris 10 OS for SPARC platforms has removed all static system libraries and statically linked commands.)

To assure that your application does not violate the above criteria for the Solaris 10 ABI compatibility, you should test your application for the Solaris 10 ABI compatibility to make sure that it runs in the new environment.

The Solaris Application Scanning Tool, which is part of the SolCAT tools described in the section called "Solaris Compatibility Assurance Toolkit (SolCAT)", is a fast and easy check to see whether your application is compliant with Solaris ABIs. You specify the targeted OS release (for example, Solaris 10) that the Solaris Application Scanning Tool will check against your application. If you don't see any warning or error messages from the Solaris Application Scanning Tool test results, your application should run on the Solaris 10 OS. If you are on the fast track, your application is ready for production release.

Qualifying on the Solaris 10 OS

You should qualify your application for the Solaris 10 OS if the application has any of the following characteristics:

• It includes a kernel module or device driver.
• It uses the new Solaris 10 OS API.
• It is multithreaded and uses the UNIX International (aka "Solaris") instead of POSIX thread library (see process model unification in the section called "API Enhancements" for details).
• It has been recompiled.
• It has been modified.
• It shows an error or warning message when running SolCAT.

Setting Up a Development Environment

Based on your adoption strategy or the SolCAT test results, you may need to set up a development environment for the Solaris 10 OS. The following sections describe the steps necessary to set up a development environment for Solaris 10 OS adoption. These steps include:

• Getting the Solaris 10 Software
• Getting Solaris 10 Development Tools (Compilers)
• Getting Solaris 10 Documentation
• Understanding Food Chain Dependencies
• Identifying Systems to Qualify Your Application

Getting Solaris 10 Software Through the iForce Solaris 10 Early Adoption Program

To participate in the Solaris 10 Early Adoption program, your company must become a registered member in the iForce Partner partner program. After your company becomes an iForce partner, you can log in to the iForce membership center with the password provided to you. The Solaris 10 Operating System icon in the upper left corner of the iForce membership center takes you to the Solaris 10 Early Adoption program page. The Solaris 10 adoption program page provides the ISV with high-quality snapshots of the Solaris OS currently under development. This software is fully functional with predictable and regular release schedules (monthly in most cases) of the software.

The official release of Solaris 10 software is available for download. The development release of Solaris 10 Update software is also freely available from the Sun Software Express Program. With Software Express for Solaris, Sun is making the latest technologies available, built from the development team's work-in-progress code base released at monthly intervals.

Getting Development Tools

Sun Studio software supports the Solaris 10 OS. Sun Studio software is full of productivity enhancements, feature improvements, and expanded platform support that includes Linux, x86 architecture, and AMD Opteron processors, and it is recommended for development with the Solaris 10 OS. Sun Studio software is designed to help you achieve a better runtime as well as shorter build time. Sun Studio 10 software is optimized to support AMD Opteron 64-bit processors.

See the section of this article called "Using Sun Studio Software for the Solaris 10 OS" for more information.

Getting Solaris 10 Documentation

Food Chain Dependencies

You may use third-party tools in your development, include third-party libraries in your application, or bundle third-party applications with your product. In most cases, this third-party software should run on the Solaris 10 OS. We recommend that you use SolCAT tools to test third-party software ABI compatibility. If the third-party software is incompatible with the Solaris ABI, SolCAT tools show warnings or error messages to identify problems for you to discuss with your food chain vendors.

Identifying Qualified Systems

The Solaris 10 OS requires a minimum of 64 Mbyte of memory and 1 Gbyte of disk space for server systems. The Solaris 10 OS supports all UltraSPARC II, III, and IV platforms, and the following Sun x64/x86 based systems:

• Sun Fire V20z Server -- One or two AMD Opteron 200 Series processors, up to 16 Gbyte DDR1-333 SDRAM, two 10/100/1000-Mbps Ethernet, two 64-bit PCI-X slots, up to two hot-swappable 3.5-inch x 1.0-inch Ultra320 SCSI drives
• Sun Fire V40z Server -- Four AMD Opteron 800 Series processors, up to 32 Gbyte DDR1-333 SDRAM, two 10/100/1000-Mbps Ethernet, seven 64-bit PCI-X slots, up to six hot-swappable 3.5-inch x 1.0-inch Ultra320 SCSI drives
• Sun Fire B200x Blade Server -- Dual Xeon processors, 2 Gbyte or 4 Gbyte DDR memory options, four gigabit Ethernet interfaces, dual slot, 3U self-enclosed Blade
• Additional x86 platforms as listed in the Hardware Compatibility List may also be supported by the Solaris 10 OS.

Helpful Hint

If you have a spare disk larger than 4 Gbyte, you may want to install the Solaris 10 OS on that disk without changing the existing boot disk. During the installation, the installer will prompt you for a selection of disk to install the OS.

Solaris Compatibility Assurance Toolkit (SolCAT)

Sun currently provides SolCAT, an extensible tool framework to help ISVs, developers and system administrators test compliance with the Solaris ABI and ease adoption to the Solaris 10 OS.

The Solaris Compatibility Assurance Toolkit currently consists of two complementary tools that examine applications' usage of the Solaris library ABI:

• Solaris Application Scanner that checks if the application uses nonexistent interfaces
• Solaris Appcert that checks if the application uses undocumented and unsupported interfaces

The two tools examine ELF binaries' usage of the Solaris library ABI for C, C++, Fortran, Cobol, compiled applications, and so on. Other aspects of the ABI: interpreted programs (for example, Java technology-based applications and shell scripts), use of utility commands, configuration files, and device drivers, and the like are out of the scope of these tools.

These tools may be scanned over application binaries to detect issues that might affect the application's compatibility when run on a later Solaris release. Both tools have been updated to test for issues up to and including the Solaris 10 OS.

The following section provides:

• Overview of the tools
• List of what the tools check for
• Instructions on installing the tools
• Instructions on running the tools
• Examples of running the tools
• How to interpret their output

Solaris Application Scanner

The Solaris Application Scanner was created in response to feedback from Solaris Appcert users that wanted a tool with the following features:

• Results that were easier to understand than Solaris Appcert's
• A "Go/No-Go" decision for an application
• Faster running time than Solaris Appcert when run over many binaries

The resulting tool focuses on a relatively straightforward check: Does the application directly call any Solaris interfaces or libraries that have gone away in a Solaris release? If so, the application has a very high chance of failing when run on that Solaris release.

Given an application binary with a Solaris Application Scanner "No-Go" status, the only ways the application would not fail at runtime are:

• The application (in principle or in practice) never calls the removed interface.
• The application (using its own support shared objects) provides its own implementation of the removed interface.
• An accidental coincidence exists between the name of the Solaris interface that was removed and one the application provides to itself (using its own support shared objects).

These cases are all relatively rare (and are listed above in order of increasing rarity), and therefore a No-Go result from Solaris Application Scanner should be taken seriously.

Since Sun believes binary compatibility for the Solaris platform is very important, it is extremely rare for public interfaces or libraries to be removed. A lengthy End-Of-Life process is performed before doing so. For private interfaces and libraries (that is, those intended only for Solaris-internal usage: they are not part of the API/ABI), no such constraint exists (because applications are not supposed to be using them). For more information on Sun's EOL process see: Solaris OS Life Cycle.

The Solaris Application Scanner database contains information on both public and private interfaces that have been removed from the Solaris OS. The private interfaces are included in case an application has been using the private interfaces and has "just happened to work" until the private interface is removed. Because public interfaces are only rarely removed from the Solaris OS, the vast majority of the Solaris Application Scanner database consists of removed private interfaces.

The Solaris Application Scanner tracks removal of interfaces and libraries from Solaris 2.4 up to and including the Solaris 10 OS.

Appcert Tool for the Solaris OS

The Solaris Appcert tool has been updated to handle some additional potential binary compatibility problems specific to the Solaris 10 OS. In addition, its symbol database has been updated to provide a "snapshot" of the Solaris 10 OS to go along with its existing snapshots for releases from Solaris 2.3 to Solaris 9.

The Solaris Appcert tool takes a somewhat different approach from Solaris Application Scanner: Solaris Appcert looks for and reports potential binary incompatibilities. That is to say, its primary function is to give "heads-up" warnings about vulnerabilities in the application that could lead to failure when run on future Solaris releases. The main check Appcert performs is for the application's direct usage (that is, calling) of private interfaces in the Solaris OS.

The developer of an application will be interested in removing all Solaris Appcert-reported vulnerabilities from the application (by modifying the application source code and rebuilding and redeploying). Similarly, a system administrator or quality assurance test engineer may decide to perform extra testing on newer Solaris releases of applications that yielded Solaris Appcert warnings.

Some overlap exists in the checking that Solaris Appcert and Solaris Application Scanner perform, in particular: Solaris Appcert does check for usage of a large number of interfaces or libraries that have been removed. These checks are most concerned with public interfaces or libraries that have been removed (although quite a few private interfaces are included as well), while the Solaris Application Scanner has a large database of essentially all interfaces (public or private) that have been removed.

Solaris Appcert has some miscellaneous checks for potential binary incompatibility problems not simply involving private interface usage. The checks added in this Solaris 10 release are:

• Manipulates lightweight processes directly instead of using thread (some _lwp_* interfaces may be removed)
• Non-POSIX libthread fork(2) call (A rare chance exists that an application may need to switch to forkall(2))
• Potential source code incompatibility from makecontext(3C) (source code issue only when rebuilt on the Solaris 10 OS or later)
• SunOS 4.x a.out (non-ELF) binaries (warning only, no BCP EOF yet planned)
• Usage of deprecated and EOL interface 64-bit ptrace(2)
• Usage of deprecated and EOL interface auditsvc(2)
• Usage of deprecated and EOL interfaces sysmem/asysmem (accidentally introduced into and removed from SVID)
• Usage of deprecated libXinput.so.0 (should migrate to X11 standard libXi.so.1)
• Usage of EOL libldap.so.3 (should migrate to libldap.so.4 or libldap.so.5 standards)
• Usage of EOL libxfn.so
• Usage of EOL libkcs.so.1
• Usage of /usr/lib/libproc.so.1 interfaces (these interfaces remain private)
• Usage of removed private library libdevfsevent.so.1
• Usage of removed private library libdhcp.so.2
• For more information, see End-of-Software Support Statements

For more information on SolCAT, see Solaris ABI Tools - SolCAT.

New Features in the Solaris 10 OS

The Solaris 10 OS introduces many new features to improve system performance, availability, utilization, security, and platform choice.

• Solaris Containers -- A system virtualization mechanism allowing one or more processes to run in isolation from other activities on the system.
• Predictive Self-Healing -- A new software architecture and methodology for fault management across all of Sun's product line. This includes both Fault Manager and Solaris Services Manager to increase system and services availability.
• ZFS -- A new file system that provides strong data integrity guarantees, simple administration, and immense capacity. This feature is transparent to applications.(This is an upcoming technology in the Solaris 10 OS.)
• Process Rights Management -- Fine-grained security access control (privileges) of processes. This allows for processes with a non-0 effective UID to have selected process rights that originally were only root's prerogative, as well as tightly controlling the privileges of a UID 0 process.
• High Performance Networking -- An enhanced networking stack to provide better performance and scalability while enabling a path for delivering advanced functionality. This feature is transparent to applications.
• Memory Placement Optimization (MPO) -- MPO allows applications optimization on machines with asymmetric hardware memory configurations. (Also available in Solaris 9 12/02 and later updates.)
• Chip Multithreading Support -- Enhanced thread scheduling policies to improve system performance through better cache utilization and by maximizing aggregate resource availability. This feature is transparent to applications.
• Solaris Cryptographic Framework -- A developer's framework for adding encryption of data within an application and for encryption transactions on the Internet. Based on de facto PKCS#11 standard.
• Secure WAN Boot -- WAN Boot enables systems to be booted and installed over a public data network (WAN) using authentication and encryption as appropriate. This feature is transparent to applications. (Also available in Solaris 9 4/04 and later updates).
• Dynamic Tracing (DTrace) -- Adds dynamic instrumentation and tracing to the kernel for use on both production and development systems. This feature is transparent to applications.
• IP Filter -- Stateful packet filtering by IP address, port, protocol, network interface, and traffic direction. IP filter also provides Network Address Translation (NAT) to hide details of internal networks and act as a gateway to the Internet. This feature is transparent to applications.

New Features That May Require Application Changes

Many of the new features are transparent to the application and require no modification to the application. Some features need application inputs, application knowledge of system configuration, or a system dependency check. These features require the application to make the appropriate changes to adopt the feature. Such changes may include the following:

• Source code
• Packaging
• Installation script

The features that might require changes to an application include:

• Solaris Containers
• Process Rights Management
• Predictive Self Healing
• Memory Placement Optimization
• Cryptographic Frameworks

Solaris Containers introduce a way to create virtualized operating system environments within an instance of the Solaris OS. Solaris Containers offer a software partitioning technology that effectively isolates the resources, security, identity, name spaces, and faults of one container from other containers. Solaris Containers allow the customer to install, deploy and run an application on a shared system in complete privacy.

Solaris Containers are a whole new way of creating multiple soft partitions within the Solaris OS, each with their own hostname, IP addresses, users, root user, private file system, network ports, and so on. Processes running in these containers are fully isolated and secure from other processes running in the other containers. They cannot see each other or signal each other, they can only communicate through the network stack or a shared file system link between two separate systems.

Supporting the container is a single kernel that creates separate identity environments, controlling what the applications and users are allowed to see and access. The users in the containers, even root, only control a subset of the environmental settings (that is, physical device settings, network routing tables, and so forth), which prevents them from endangering the system as a whole.

The file system within the container is partly private (/etc, /var, and so on) and partly shared (/usr, /lib, and so on). The shared file systems are only readable and not writeable from the containers, which again helps make sure that one environment cannot negatively impact one another. This also allows the container to be the size of the actual application (plus some space for the identity), and you don't need to waste system resources on replicating the same system-related files.

A tutorial is available on the Solaris 10 ISV Adoption Kit site that gives step-by-step procedures on how to get started using Solaris Containers.

The general task outline covers:

• How to create the zone's configuration
• How to install the zone
• How to create and boot the zone
• How to enter the zone

Solaris Containers can be configured on any machine on which the Solaris 10 OS can be installed. Each Solaris Container requires approximately 100 Mbyte of disk space. An additional 40 Mbyte of RAM per container is helpful, but not required, as long as you have enough swap space.

Additional resources may be required for applications running in a container (without inducing a lot of paging). These requirements vary with the application in question.

Please refer to the BigAdmin article Solaris Zones Partitioning Technology.

Process Rights Management helps ISVs to mitigate the risk that their application may harm the system and data by out-of-control processes or malicious software (worms, viruses, and so on). Process rights management can provide a more secure and available operating environment.

The principle of Process Rights Management requires that a user be given the minimal process rights necessary to perform a job.

Ensuring minimal process rights requires:

• Identifying what the user's job is
• Determining the minimum set of process rights required to perform that job
• Restricting the user to a domain or a Solaris container with those process rights and nothing more

The Solaris 10 OS implementation of process rights management extends the process rights model with the concept of process rights sets. Each process rights set contains zero or more process rights. With process rights sets, minimal process rights sets add support for fine-grained process rights to the Solaris OS. In addition, process rights sets provide the Solaris OS with the ability to:

• Give some of the superuser's capability to individual processes without requiring them to run with full root (UID 0) process rights
• Restrict processes to run SetUID root to only the privileges it actually requires
• Limit a process and its offspring to a limited set of process rights

The Solaris 10 OS introduces the concept of process privileges by granting access to privileged applications. The traditional UNIX superuser (UID 0) no longer has special meaning, although for compatibility purposes the Solaris 10 OS ships with the expected set of privileges assigned to that user ID.

Developers who create new privileged applications should test for specific privileges instead of checking to see if their effective user ID is 0. See section 2, "Developing Privileged Applications", in the Solaris Security for Developers Guide for adopting Process Rights Management in your application.

Predictive Self Healing provides a new software architecture and methodology for fault management across Sun's product line. Predictive Self Healing consists of two major components: Solaris Fault Manager and Solaris Services Manager to increase system and services availability.

Solaris Fault Manager allows system errors and faults to be logged and retrieved for fault diagnosis, isolation, self-healing, and proactive prevention. This, in general, is transparent to applications.

Solaris Services Manager, as implemented by the Service Management Facility (SMF), is a new framework for simplifying management of Solaris system services. A Service is defined as an entity that has both these characteristics:

• It is composed of a set of devices or processes.
• It provides a known list of capabilities to the user or to other local and remote services.

A service itself may be dependent on a declared list of other services. UNIX has traditionally included a set of services that are initialized, invoked, executed, and managed independently of each other. SMF replaces the existing service mechanism in the Solaris OS with three primary goals:

• Supply a mechanism to formalize relationships between services.
• Provide a unified repository for configuration of service startup behavior.
• Allow the Solaris OS to start and restart services automatically over the lifetime of a Solaris instance.

To achieve these goals, the SMF framework includes the following components:

• Service abstraction -- Service is the fundamental unit of administration in the SMF framework. The service abstraction includes properties and methods. A service may have multiple instances.
• Repository -- The repository is responsible for storing persistent configuration information as well as the SMF runtime data for services.
• Repository cache daemon -- A daemon process manages the SMF repository. The daemon maintains an in-memory cache for active queries and transactional writes.
• Repository library interfaces -- A set of functions facilitates the creation and manipulation of services and instances, interacting with property groups, administrative consoles, observational tools, and service methods.
• Master restarter daemon -- This daemon is responsible for managing the restart relationships among all service instances on the system. It also manages the state for all instances not explicitly managed by a delegated restarter.
• Delegated restarters -- Delegated restarters are specialized services that take over the state management of a set of service instances in the SMF from the master restarter. A set of APIs is provided to developers for developing delegated restarters.
• init(1M) modifications -- To start the SMF processes that include the repository cache daemon and master restarter daemon.
• Command-line administrative utilities -- A set of command-line interfaces allow users to observe and manipulate services, service instances, and properties.

SMF allows applications to define services relationship and to invoke actions upon these relationship. Application developers define service relationships with a "service manifest" and use svccfg(1M) and svcadm(1M) to import the manifest to the service repository. A service manifest is an XML file that resides in the SMF repository. A SMF daemon performs actions on services according to the specification in the manifest.

Memory Placement Optimization (MPO) allows the Solaris OS to recognize and capitalize on memory locality effects present in Sun's large servers. It introduces several APIs for an application to dynamically determine how its threads and virtual memory have been assigned to processors and physical memory. Additional information on MPO and its associated APIs is available in the Memory Placement Optimization white paper (pdf).

Solaris Cryptographic Framework

The Solaris Cryptographic Framework provides optimized implementations of common cryptographic (encryption and message hashing) algorithms and a plug-in framework to abstract the implementation and calling requirements of individual cryptographic algorithms.

The framework allows security application provider (for example, SSL, SSH, IKE, and JCE) to have a common interface to algorithms for:

• Encryption (DES, 3DES, AES, Blowfish, Arc4 [aka RC4])
• Message Digests (MD5, SHA1)
• Signing (RSA, DSA, DH)
• Random number generation
• HW acceleration

The framework adopts the PKCS#11 v2.11 API as the interface for applications. (See pdf version available via FTP: PKCS #11 v2.11: Cryptographic Token Interface Standard.) Applications are not able to call individual cryptographic algorithms directly but are required to provide key material (where appropriate) and specification of which algorithm(s) they wish to use. This abstracts the applications from the implementation details of given algorithms.

The PKCS#11 API is also used as the Service Provider Interface (SPI) for ISVs and third parties to replace or augment provided algorithms. Using PKCS#11 as the SPI allows easy access to third-party cryptographic tokens such as hardware accelerator cards and smart card-like products used for secure key storage.

For more detailed information, see the description of the Solaris Cryptographic Framework in the Solaris 10 OS Adoption Kit.

API Enhancements in the Solaris 10 OS

The Solaris 10 OS introduces many API enhancements to provide additional functionality, improved performance, better standard compliance, and easy of use with multi-threaded programming. ISVs have the option of adopting new APIs, and modifying existing APIs. Multithreading applications may experience additional restrictions and should be certified on the Solaris 10 OS.

The Solaris 10 API enhancements include:

• New API frameworks
• Change to existing APIs
• Replacement of existing APIs
• EOL of existing APIs

New API Frameworks

Event Ports provide a mechanism to generate and collect notifications about completed asynchronous transactions. Transactions are asynchronous reads and writes as well as interactions between application and kernel that require an asynchronous completion notification. This framework is a scalable and unified way to serve multiple clients, waiting on multiple objects simultaneously without degrading overall performance.

User-Level Atomic Operation Functions provide atomic operation for use by user-level threads programmers.

Layered Driver Framework (LDF) provides a set of kernel APIs for accessing devices from within the kernel and enhancements in libdevinfo(3DEVINFO) for retrieving device usage information inside the kernel (see the Enhanced Interfaces page of Solaris 10 Adoption Kit).

User Direct Access Programming Library (uDAPL) defines a single set of user APIs for all RDMA-capable transports.

Simple Authentication and Security Layer (SASL) provides support for authentication, privacy, and integrity services for connection-based protocols as described in RFC 2222.

In addition to above new API frameworks, the Solaris 10 OS also introduces many new functions to existing APIs. A complete list of new functions is available in the Solaris 10 Adoption Kit on the iForce Partner partner web site.

API Enhancements

Process model unification unifies the process model for single-threaded process with multi-threaded process. Process model unification makes several changes that might affect applications:

1. Merging libthread and libpthread into libc

• Linking with libthread or libpthread is no longer necessary for multithreaded applications
• EOL of _lwp_create(2), _lwp_detach(2), _lwp_exit(2), _lwp_getprivate(2)_lwp_makecontext(2), _lwp_setprivate(2), and _lwp_wait(2) system calls

2. Removing all static binaries

• Remove all static libraries.
• Remove statically linked system commands in /usr/sbin/static/.
• Convert Solaris static and partially static executables into dynamically linked executables.
• /lib is a real directory instead of a symbolic link to /usr/lib. /lib includes libraries that are needed before /usr is mounted.

3. Making fork(2) behave consistently between Solaris threads and POSIX threads. The semantics of fork(2) for multithreaded applications that use the Solaris thread API (linked with -lthread) are identical to fork1(2), only the calling thread is replicated in the child process. A new system call, forkall(2), is provided to replicate all of the parent process's threads in the child process. Note: An application that is multithreaded and uses the Solaris thread library needs to be fully qualified under the Solaris 10 OS.

Single UNIX Specification Version 3 (SUSv3) implements optional features specified by the new SUSv3 standard.

In addition to the above enhanced API frameworks, the Solaris 10 OS also includes many enhanced functions. A complete list of enhanced functions is available in the Solaris 10 Adoption Kit on the iForce Partner partner web site.

EOL Libraries, Packages, and Modules

32-bit SPARC kernels -- The SPARC 32-bit kernel is no longer supplied with the Solaris 10 OS. Existing 32-bit applications are not affected as the 64-bit kernel supports both 32-bit and 64-bit applications.

Solaris Static System Libraries -- All 32-bit static system libraries and statically linked utilities (for example, /usr/sbin/static) are removed from the Solaris 10 OS.

X11 Static Libraries -- All X11 static libraries are removed from the Solaris 10 OS: libX.a, libXaw.a, libXi.a, libXt.a, libdpstk.a, libX11.a, libXdmcp.a, libXmu.a, libXtst.a, libpsres.a, libXau.a, libXext.a, libXp.a, and libdps.a.

libXinput.so.1 -- libXinput is retained in the Solaris 10 OS. However, it is strongly recommended to remove the dependency of libXinput in your application as libXinput may be removed in a future Solaris release.

pam_unix.so.1 -- The pam_unix(5) module is no longer supported. Similar functionality is provided by pam_authtok_check(5), pam_authtok_get(5), pam_authtok_store(5), pam_dhkeys(5), pam_passwd_auth(5), pam_unix_account(5), pam_unix_auth(5), and pam_unix_session(5).

_lwp*(2) system calls -- With libthread folded into libc, all applications are multithreaded, and calls directly to any of these functions could cause the process to malfunction.

Interprocess Communication (IPC) kernel tunables -- All IPC kernel tunables are replaced by the Solaris resource controls framework. See prctl(1) for details.

64-bit Packages -- Solaris releases 7, 8, and 9 included separate packages for 32-bit and 64-bit components. In general, the name of a packages delivering a 64-bit component was the same as the equivalent 32-bit package name with the letter "x" appended.

In the Solaris 10 Operating System for SPARC platforms, 32-bit and 64-bit components are delivered together in a single package. The combined packages retain the names of the original 32-bit packages, and the 64-bit packages are no longer delivered. For example, /usr/lib/sparcv9/libc.so.1, which in Solaris 7, 8, and 9 was delivered in SUNWcslx, is now delivered in SUNWcsl.

Packages which only deliver 64-bit components have been renamed to remove the trailing "x." For example, SUNW1394x has become SUNW1394.

Note: The sun4u 200 MHz and below platforms (UltraSPARC-1) are no longer supported in the Solaris 10 OS.

A complete list of removed functions, commands, packages, and modules is available in the Solaris 10 Adoption Kit on the iForce Partner partner web site.

The Solaris 10 OS on x86 Platforms

The Solaris OS for x86 and SPARC Based Systems

Solaris has one code base for all supported platforms and systems; thus, the API differences for any given platform are negligible.

All libraries available for the Solaris OS on SPARC platforms are also available for the Solaris OS on x86 platforms. Some of the libraries, such as libGL.so, are available only on the SPARC platform.

The major differences between platforms from a developer's point of view are at the Instruction Set Architecture (ISA) level, and are rarely encountered in high-level applications. These may include:

• Byte ordering -- SPARC hardware implements big-endian addressing (Most Significant Byte [MSB] is stored in the lowest memory address) whereas x86 hardware implements little-endian addressing (Least Significant Byte [LSB] is stored in the lowest memory address).
Data alignment -- x86 has no alignment restrictions on data types. On SPARC platforms, all quantities must be aligned on their natural boundaries. Because of the data alignment restrictions imposed by the SPARC processor, C structures also have alignment requirements. Structure alignment requirements are imposed by the most strictly aligned structure component. For example, a structure containing only characters has no alignment restrictions, while a structure containing a long long member must be constructed to guarantee that this member falls on a 64-bit boundary.
• Floating Point Operation differences -- On x86 systems, the floating-point registers are 80 bits wide, while on the SPARC systems, the floating point registers are 64 bits wide. Due to this, the computation results can differ because intermediate results of arithmetic computations can be in extended precision. Please refer to the Numerical Computation Guide for further details.

A guide to adding x86 support for existing SPARC applications discusses various solutions to address these ISA differences.

Porting From SPARC Platforms to x86 Platform

In most cases, an application for the Solaris OS on SPARC platforms is expected to work after a recompile on the x86 platform. A few instances may require changes to source code or makefiles. You may want to read the previous section and x86 porting guide first. Also available for your reference are:

• Technical Case Study: Porting Apache Web Server from Solaris OS on SPARC Platforms to Solaris OS on x86 Platforms. This article presents a case study of porting an application for the Solaris OS from the SPARC platform to the x86 platform.
• Compiler Differences Between Solaris OS on the SPARC Platform and Solaris OS on the x86 Platform discusses differences between the compilers.

Porting From Linux to the Solaris OS

This presents a more challenging task than porting a Solaris application from the SPARC platform to the x86 platform. Some of the porting issues involve:

• Difference in process management as implemented in the /proc file system.
• Header files -- Linux and the Solaris OS have slightly different header file structures.
• System calls and C library -- A number of the Linux APIs available on the Solaris OS have different return and parameter types, or are declared in different header files. However, these differences are often minor and typically do not require code changes in the application.
• Third-party tools, utilities, and libraries -- Most popular third-party tools, utilities, and libraries commonly found on Linux are also available on the Solaris OS. You may want to check Solaris Operating System Freeware to see what utilities are already included in a Solaris distribution, or Sunfreeware.com to find additional unbundled packages for the Solaris OS.
• Testing suites -- Due to differences in some command interfaces, you may need to make some changes to your Linux test suites for use on the Solaris OS.

Third-Party Hardware Supported by the Solaris OS on x86 Platforms

The Hardware Compatibility List identifies x86 hardware known to be compatible with the Solaris OS. Three levels of compatibility are included:

• Sun Certified -- Sun Certified hardware refers to Sun systems and other third-party system configurations and components running Solaris. Products listed in this category are certified by Sun.
• Test Suite Certified -- Test Suite Certified hardware refers to third-party system configurations or components that have been certified using the Hardware Certification Test Suite (HCTS). Testing is carried out by a partner or vendor. Once an audit has been completed and passed, certified hardware is eligible for listing on the HCL. Test Suite Certified hardware is certified at Level 1 or at Level 2. Level 2 certification is more rigorous and puts more stress on the hardware.
• Reported to Work -- Hardware listed in this category is reported to operate with the Solaris OS. Sun appreciates the contributions of the user community in providing this data. To be listed in this category, it is not required to run the HCTS.

The HCL includes systems (server, desktop, and laptop) as well as components.

Using Sun Studio Software for the Solaris 10 OS

Sun Studio software is an integrated set of tools for the development of enterprise-class applications targeting Sun platforms -- primarily via native C, C++, or Fortran binaries, with support for work that combines native code and the Java programming language.

Sun Studio Software Support for Solaris 10 OS

Sun Studio 10 software provides a comprehensive, productive environment for developing scalable C, C++, and Fortran 32-bit and 64-bit applications on Sun's newest UltraSPARC IV and AMD processor-based systems for the Solaris Operating System.

The Sun Studio 10 product includes software for the Solaris OS, for both the SPARC and x64/x86 platforms. Earlier versions of the software such as Forte 6 Update 2, Sun ONE Studio 7 Enterprise Edition, and Sun Studio 8, are easily upgradeable to Sun Studio 10 since it is fully compatible with all of these former releases.

Sun Studio 10 software is full of productivity enhancements, feature improvements, and expanded platform support to make your Solaris application development more productive.

Sun Studio 10 runs on the Solaris 10 OS. Key features and benefits include:

• Improved SPARC Performance: Usage of optimizations with -O in Sun Studio 10 can improve applications by up to 40 percent over Sun Studio 8 software.
• Improved Xeon and AMD Performance: Runtime performance for applications generated for the Solaris OS on x86 platforms is now up to 60 percent faster. SSE and SSE2 optimizations are available for Pentium-compatible Intel and AMD chips.
• New Xeon and AMD High Performance Features: Fortran 90/95 and the Sun Performance Library are now available for the Solaris OS on x86 platforms, making it easy to deploy high-performance applications on IA 32 and AMD 32-based systems.
• Simplified Debugging: Graphical user interface allows for easy access to advanced debugging features. Set breakpoints, examine variables, and navigate the call stack through debugger menus and buttons. Reduce turnaround time for fixes and achieve greater debugging productivity with "Fix and Continue." Debug optimized and parallelized code as well as mixed languages (C, C++, Fortran, and Java programming language). Sun Studio 10 debugger also supports the Linux OS.
• Performance Analysis Tools: Help assess the performance of a program, identify potential performance problems and identify the section of the code where problems may be occurring. Sun Studio 10 performance analyzer also supports the Linux OS.
• Native Connector Tool: Wraps C and C++ functions and data objects, and exposes them as Java classes, enabling the deployment of C/C++ code as services.
• Multi-threaded Applications: Capability of building applications with Sun Studio 10 Open MP 2.0 support for C, C++ and Fortran code (SPARC platform only).
• 64-Bit Application Development: With 64-bit technology, applications are capable of solving larger, more complex problems.

System requirements entail 512 Mbyte of memory, 1 Gbyte of swap space, disk space of 2 Gbyte, 1.6 Gbyte Solaris OS on x86 platforms and/or .8 Gbyte Linux. The software is supported by Solaris 10, 9 and 8 OS (SPARC and x64/x86 platforms); Sun Java Desktop System, 2003; SUSE Linux Enterprise Server 8, and Red Hat Enterprise Linux 3 (debugger and performance analyzer only).

Resources Available for ISV Adoption Projects

Sun has many resources to help ISVs that are adopting the Solaris 10 OS, including:

• Solaris 10 Early Adoption program
• Solaris Adoption Kit
• SolCAT Tools
• Technical Support

Solaris 10 Early Adoption Program

The goal of the Early Adoption Program is twofold:

1. To provide you with a head start on integrating your product with the Solaris 10 OS for early market access.
2. To give you an opportunity to tell Sun how it can make the Solaris 10 OS and your product the number one choice for your customers.

The Solaris 10 Early Adoption Program provides you with:

• The latest software downloads for the Solaris 10 OS
• Online feature documentation and white papers for the Solaris 10 OS
• Free email-based adoption support for the Solaris 10 OS
• Adoption tools, including API-level checks

To participate in the Solaris 10 Early Adoption program, your company must be a registered member in the iForce Partner partner program. Becoming an iForce partner is free. The iForce Partner Program offers, to eligible Partners, substantial discounts on Sun hardware, software, and support; improved company and product visibility via Sun co-marketing programs; increased sales opportunities to Sun customers; and access to valuable customized information via our Membership Center.

After your company becomes an iForce partner, you can log in to the iForce membership center with the password provided to you. The Solaris 10 Operating System icon on the upper left corner of the iForce membership center takes you to the Solaris 10 Early Adoption program page.

Solaris 10 Adoption Kit

The Solaris 10 Operating System Adoption Kit was designed to provide you with a comprehensive guide on how to incorporate the latest features and enhancements from the Solaris 10 OS into your applications. Documentation and resources for testing, support, porting, and application recompile are included in the adoption kit. Our goal is to make it as easy as possible for your company to adopt the Solaris 10 OS.

The Solaris 10 Adoption Kit includes these sections:

• Getting Started -- We've provided you with the step-by-step process for adopting the Solaris 10 OS. Get more details on the two strategies your company can take toward adoption:
• Fast Track Adoption
• Advantage Track Adoption
• Follow the Q&A on which adoption strategy is best fits your application. Access product documentation, as well as platform-specific information.
• Why Solaris? -- Deciding about the Solaris 10 OS? Learn about the benefits of this release, and what it offers you and your customers.
• What Is New? -- Learn about the changes in the Solaris 10 OS. Find detailed feature-by-feature descriptions, definitions, porting suggestions, new and enhanced interfaces, EOL/EOF changes, and much more.
• SPARC Platform Specific -- Learn about SPARC platform-specific changes, updates, enhancements, and supported hardware platforms.
• x86 Platform Specific -- Learn about x86 platform specifics, including what is new, or what has been changed or removed. Get information on 64-bit support for AMD Opteron processors, Linux compatibility, x86 porting guides, and supported hardware platforms.

SolCAT Tools

See the preceding section called "Solaris Compatibility Assurance Toolkit (SolCAT)" for a detailed description of SolCAT.

Technical Support

Participation in the Solaris 10 Early Adoption Program qualifies you for free technical support in your adoption effort. If you encounter any technical issues, questions, or potential Solaris bugs, send an email to solaris-adoption@sun.com. Your email will be acknowledged shortly after it is received.

About the Authors

Chien-Hua Yen is a Senior Staff Engineer in Market Development Engineering at Sun Microsystems.

Fred Rehhausser is Group Marketing Manager for Solaris Platform Products at Sun Microsystems.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.