Skip to document

An Introduction to Solaris history

Course

BS Computer Science

147 Documents
Students shared 147 documents in this course
Academic year: 2020/2021
Uploaded by:
0followers
2Uploads
0upvotes

Comments

Please sign in or register to post comments.

Preview text

An Introduction to Solaris

1 A Brief History

Sun’s UNIX operating environment began life as a port of BSD UNIX to the Sun-1 workstation. The early versions of Sun’s UNIX were known as SunOS, which is the name used for the core operating system component of Solaris. SunOS 1 was based on a port of BSD 4 from Berkeley labs in 1982. At that time, SunOS was implemented on Sun’s Motorola 68000-based uniprocessor workstations. SunOS was small and compact, and the workstations had only a few MIPS of processor speed and around one megabyte of memory.

In the early to mid-1980s, networked UNIX systems were growing in popularity; networking was becoming ubiquitous and was a major part of Sun’s computing strategy. Sun invested significant resources in developing technology that enabled distributed, network-based computing. These technologies included interfaces for building distributed applications (remote procedure calls, or RPC), and operating system facilities for the sharing of data over networks (Network Information System, or NIS, and a distributed computing file system; NFS. The incorporation of remote file sharing into SunOS required extensive operating system changes. In 1984, SunOS 2 offered the virtual file system framework to implement multiple file system types, which allowed support for the NFS file system. The network file system source was made openly licensable and has subsequently been ported to almost every modern operating system platform in existence today.

The volume of applications running on the Sun platform increased steadily, with each new application placing greater demand on the system, providing the catalyst for the next phase of innovation. Applications needed better facilities for the sharing of data and executable objects. The combination of the need for shared program libraries, memory mapped files, and shared memory led to a major re- architecting of the SunOS virtual memory system. The new virtual memory system, introduced as SunOS version 4, abstracted various devices and objects as virtual memory, facilitating the mapping of files, sharing of memory, and mapping of hardware devices into a process.

During the 1980s, the demand for processing capacity outpaced the industry’s incremental improvements in processor speed. To satisfy the demand, systems were developed with multiple processors sharing the same system memory and Input/Output (I/O) infrastructure, an advance that required further operating system changes. An asymmetric multiprocessor implementation first appeared in SunOS 4—the kernel could run on only one processor at a time, while user processors could be scheduled on any of the available processors. Workloads with multiple processes could often obtain greater throughput on systems with more than one processor. The asymmetric multiprocessor implementation was a great step forward; however, scalability declined rapidly as additional processors were added. The need for a better multiprocessor implementation was obvious.

At this time, Sun was participating in a joint development with AT&T, and the SunOS virtual file system framework and virtual memory system became the core of UNIX System V Release 4 (SVR4). SVR4 UNIX

incorporated the features from SunOS, SVR3, BSD UNIX, and Xenix, as shown below. International Computers Limited (ICL) ported the new SVR4 UNIX to the SPARC processor architecture and delivered the reference source for SVR4 on SPARC.

With the predicted growth in multiprocessor systems, Sun invested heavily in the development of a new operating system kernel with a primary focus on multiprocessor scalability. The new kernel allowed multiple threads of execution and provided facilities for threading at the process (application) level. Together with fine-grained locking, the new kernel provided the foundation for the scalability found in Solaris today. The new kernel and the SVR4 operating environment became the basis for Solaris 2.

This change in the base operating system was accompanied by a new naming convention; the Solaris name was introduced to describe the operating environment, of which SunOS, the base operating system, is a subset. Thus, the older SunOS retained the SunOS 4 versioning and adopted Solaris 1 as the operating environment version. The SVR4-based environment adopted a SunOS 5 versioning (SunOS 5 being the first release) with the Solaris 2 operating environment. The naming convention has resulted in most people referring to the pre-SVR4 releases as SunOS, and the SVR4-based releases as Solaris. Table 1-1 traces the development of Solaris from its roots to Solaris 7.

The new Solaris 2 operating environment was built in a modular fashion, which made possible its implementation on multiple platforms with different instruction set architectures. In 1993, Solaris was made available for Intel PC-based architectures, greatly expanding the platforms on which Solaris is available. In October 1999, Sun announced support for Solaris on the Intel Itanium processor.

The next major milestone was the introduction of a 64-bit implementation, in Solaris 7. Full 64-bit support allows the kernel and processes to access large address spaces and to use extended 64-bit data types. Solaris 7 also provides full compatibility for existing 32-bit applications, supporting concurrent execution of 32-bit and 64-bit applications.

1 Key Differentiators

Solaris development has continued aggressively throughout the 1990s. Several key features distinguish Solaris from earlier UNIX implementations.

  • Symmetric multiprocessing — Solaris is implemented on systems ranging from single-processor systems to 64-processor symmetric multiprocessor servers. Solaris provides linear scalability up to the currently supported maximum of 64 processors. • 64-bit kernel and process address space — A 64-bit kernel for 64-bit platforms provides an LP64 execution environment. (LP64 refers to the data model: long and pointer data types are 64 bits wide.) A 32-bit application environment is also provided so that 32-bit binaries execute on a 64-bit Solaris kernel alongside 64-bit applications.

  • Processor partitioning and binding — Special facilities allow fine-grained processor control, including binding processes to processors. Processors can be configured into scheduling groups to partition system resources.

  • Demand-paged virtual memory system — This feature allows systems to load applications on demand, rather than loading whole executables or library images into memory. Demand-paging speeds up application startup and potentially reduces memory footprint.

  • Modular virtual memory system — The virtual memory system separates virtual memory functions into distinct layers; the address space layer, segment drivers, and hardware-specific components are consolidated into a hardware address translation (HAT) layer. Segment drivers can abstract memory as files, and files can be memory-mapped into an address space. Segment drivers enable different abstractions, including physical memory and devices, to appear in an address space.

  • Modular device I/O system — Dynamically loadable device and bus drivers allow a hierarchy of buses and devices to be installed and configured. A device driver interface (DDI) shields device drivers from platform-specific infrastructure, thus maximizing portability of device drivers.

  • Integrated networking — With the data link provider interface (DLPI), multiple concurrent network interfaces can be configured, and a variety of different protocols—including Ethernet, X, SDLC, ISDN, FDDI, token bus, bi-sync, and other datalink-level protocols—can be configured upon them.

10 An Introduction to Solaris

  • Integrated Internet protocol — Solaris implements TCP/IP by use of the DLPI interfaces.

  • Real-time architecture — The Solaris kernel was designed and implemented to provide real-time capabilities. The combination of the preemptive kernel, kernel interrupts as threads, fixed priority scheduling, high-resolution timers, and fine-grained processor control makes Solaris an ideal environment for real-time applications.

The differentiators listed above represent many innovative features integrated in the Solaris kernel. In the remaining chapters, we closely examine the core modules and major subsystems of the kernel.

Was this document helpful?

An Introduction to Solaris history

Course: BS Computer Science

147 Documents
Students shared 147 documents in this course
Was this document helpful?
An Introduction to Solaris
1.1 A Brief History
Sun’s UNIX operating environment began life as a port of BSD UNIX to the Sun-1 workstation. The early
versions of Sun’s UNIX were known as SunOS, which is the name used for the core operating system
component of Solaris. SunOS 1.0 was based on a port of BSD 4.1 from Berkeley labs in 1982. At that
time, SunOS was implemented on Sun’s Motorola 68000-based uniprocessor workstations. SunOS was
small and compact, and the workstations had only a few MIPS of processor speed and around one
megabyte of memory.
In the early to mid-1980s, networked UNIX systems were growing in popularity; networking was
becoming ubiquitous and was a major part of Sun’s computing strategy. Sun invested significant
resources in developing technology that enabled distributed, network-based computing. These
technologies included interfaces for building distributed applications (remote procedure calls, or RPC),
and operating system facilities for the sharing of data over networks (Network Information System, or
NIS, and a distributed computing file system; NFS. The incorporation of remote file sharing into SunOS
required extensive operating system changes. In 1984, SunOS 2 offered the virtual file system framework
to implement multiple file system types, which allowed support for the NFS file system. The network file
system source was made openly licensable and has subsequently been ported to almost every modern
operating system platform in existence today.
The volume of applications running on the Sun platform increased steadily, with each new application
placing greater demand on the system, providing the catalyst for the next phase of innovation.
Applications needed better facilities for the sharing of data and executable objects. The combination of
the need for shared program libraries, memory mapped files, and shared memory led to a major re-
architecting of the SunOS virtual memory system. The new virtual memory system, introduced as SunOS
version 4, abstracted various devices and objects as virtual memory, facilitating the mapping of files,
sharing of memory, and mapping of hardware devices into a process.
During the 1980s, the demand for processing capacity outpaced the industry’s incremental
improvements in processor speed. To satisfy the demand, systems were developed with multiple
processors sharing the same system memory and Input/Output (I/O) infrastructure, an advance that
required further operating system changes. An asymmetric multiprocessor implementation first
appeared in SunOS 4.1—the kernel could run on only one processor at a time, while user processors
could be scheduled on any of the available processors. Workloads with multiple processes could often
obtain greater throughput on systems with more than one processor. The asymmetric multiprocessor
implementation was a great step forward; however, scalability declined rapidly as additional processors
were added. The need for a better multiprocessor implementation was obvious.
At this time, Sun was participating in a joint development with AT&T, and the SunOS virtual file system
framework and virtual memory system became the core of UNIX System V Release 4 (SVR4). SVR4 UNIX