Search This Blog

Friday, November 17, 2023

Oracle Solaris

From Wikipedia, the free encyclopedia
Solaris
Screenshot of Java Desktop System on Solaris 10
DeveloperSun Microsystems (acquired by Oracle Corporation in 2010)
Written inC, C++
OS familyUnix (SVR4)
Working stateCurrent
Source modelMixed
Initial releaseJune 1992; 31 years ago
Latest release11.4 SRU61 / September 18, 2023; 60 days ago
Marketing targetServer, workstation
PlatformsCurrent: SPARC, x86-64
Former: IA-32, PowerPC
Kernel typeMonolithic with dynamically loadable modules
UserlandPOSIX
Default
user interface
GNOME
LicenseVarious
Official websitewww.oracle.com/solaris

Solaris is a proprietary Unix operating system originally developed by Sun Microsystems. After the Sun acquisition by Oracle in 2010, it was renamed Oracle Solaris.

Solaris superseded the company's earlier SunOS in 1993, and became known for its scalability, especially on SPARC systems, and for originating many innovative features such as DTrace, ZFS and Time Slider. Solaris supports SPARC and x86-64 workstations and servers from Oracle and other vendors. Solaris was registered as compliant with the Single UNIX Specification until 29 April 2019.

Historically, Solaris was developed as proprietary software. In June 2005, Sun Microsystems released most of the codebase under the CDDL license, and founded the OpenSolaris open-source project. With OpenSolaris, Sun wanted to build a developer and user community around the software. After the acquisition of Sun Microsystems in January 2010, Oracle decided to discontinue the OpenSolaris distribution and the development model. In August 2010, Oracle discontinued providing public updates to the source code of the Solaris kernel, effectively turning Solaris 11 back into a closed source proprietary operating system. Following that, OpenSolaris was forked as Illumos and is alive through several illumos distributions. In September 2017, Oracle laid off most of the Solaris teams.

In 2011, the Solaris 11 kernel source code leaked. Through the Oracle Technology Network (OTN), industry partners can gain access to the in-development Solaris source code. Solaris is developed under a proprietary development model, and only the source for open-source components of Solaris 11 is available for download from Oracle.

History

In 1987, AT&T Corporation and Sun announced that they were collaborating on a project to merge the most popular Unix variants on the market at that time: Berkeley Software Distribution, UNIX System V, and Xenix. This became Unix System V Release 4 (SVR4).

On September 4, 1991, Sun announced that it would replace its existing BSD-derived Unix, SunOS 4, with one based on SVR4. This was identified internally as SunOS 5, but a new marketing name was introduced at the same time: Solaris 2. The justification for this new overbrand was that it encompassed not only SunOS, but also the OpenWindows graphical user interface and Open Network Computing (ONC) functionality.

Although SunOS 4.1.x micro releases were retroactively named Solaris 1 by Sun, the Solaris name is used almost exclusively to refer only to the releases based on SVR4-derived SunOS 5.0 and later.

For releases based on SunOS 5, the SunOS minor version is included in the Solaris release number. For example, Solaris 2.4 incorporates SunOS 5.4. After Solaris 2.6, the 2. was dropped from the release name, so Solaris 7 incorporates SunOS 5.7, and the latest release SunOS 5.11 forms the core of Solaris 11.4.

Although SunSoft stated in its initial Solaris 2 press release their intent to eventually support both SPARC and x86 systems, the first two Solaris 2 releases, 2.0 and 2.1, were SPARC-only. An x86 version of Solaris 2.1 was released in June 1993, about 6 months after the SPARC version, as a desktop and uniprocessor workgroup server operating system. It included the Wabi emulator to support Windows applications. At the time, Sun also offered the Interactive Unix system that it had acquired from Interactive Systems Corporation. In 1994, Sun released Solaris 2.4, supporting both SPARC and x86 systems from a unified source code base.

On September 2, 2017, Simon Phipps, a former Sun Microsystems employee not hired by Oracle in the acquisition, reported on Twitter that Oracle had laid off the Solaris core development staff, which many interpreted as sign that Oracle no longer intended to support future development of the platform. While Oracle did have a large layoff of Solaris development engineering staff, development continued and Solaris 11.4 was released in 2018.

Supported architectures

Solaris uses a common code base for the platforms it supports: 64-bit SPARC and x86-64.

Solaris has a reputation for being well-suited to symmetric multiprocessing, supporting a large number of CPUs. It has historically been tightly integrated with Sun's SPARC hardware (including support for 64-bit SPARC applications since Solaris 7), with which it is marketed as a combined package. This has led to more reliable systems, but at a cost premium compared to commodity PC hardware. However, it has supported x86 systems since Solaris 2.1 and 64-bit x86 applications since Solaris 10, allowing Sun to capitalize on the availability of commodity 64-bit CPUs based on the x86-64 architecture. Sun heavily marketed Solaris for use with both its own x86-64-based Sun Java Workstation and the x86-64 models of the Sun Ultra series workstations, and servers based on AMD Opteron and Intel Xeon processors, as well as x86 systems manufactured by companies such as Dell, Hewlett-Packard, and IBM. As of 2009, the following vendors support Solaris for their x86 server systems:

  • Dell – will "test, certify, and optimize Solaris and OpenSolaris on its rack and blade servers and offer them as one of several choices in the overall Dell software menu"
  • Intel
  • Hewlett Packard Enterprise – distributes and provides software technical support for Solaris on BL, DL, and SL platforms
  • Fujitsu Siemens

Other platforms

Solaris 2.5.1 included support for the PowerPC platform (PowerPC Reference Platform), but the port was canceled before the Solaris 2.6 release. In January 2006, a community of developers at Blastwave began work on a PowerPC port which they named Polaris. In October 2006, an OpenSolaris community project based on the Blastwave efforts and Sun Labs' Project Pulsar, which re-integrated the relevant parts from Solaris 2.5.1 into OpenSolaris, announced its first official source code release.

A port of Solaris to the Intel Itanium architecture was announced in 1997 but never brought to market.

On November 28, 2007, IBM, Sun, and Sine Nomine Associates demonstrated a preview of OpenSolaris for System z running on an IBM System z mainframe under z/VM, called Sirius (in analogy to the Polaris project, and also due to the primary developer's Australian nationality: HMS Sirius of 1786 was a ship of the First Fleet to Australia). On October 17, 2008, a prototype release of Sirius was made available and on November 19 the same year, IBM authorized the use of Sirius on System z Integrated Facility for Linux (IFL) processors.

Solaris also supports the Linux platform application binary interface (ABI), allowing Solaris to run native Linux binaries on x86 systems. This feature is called Solaris Containers for Linux Applications (SCLA), based on the branded zones functionality introduced in Solaris 10 8/07.

Installation and usage options

Solaris can be installed from various pre-packaged software groups, ranging from a minimalistic Reduced Network Support to a complete Entire Plus OEM. Installation of Solaris is not necessary for an individual to use the system. Additional software, like Apache, MySQL, etc. can be installed as well in a packaged form from sunfreeware and OpenCSW. Solaris can be installed from physical media or a network for use on a desktop or server, or be used without installing on a desktop or server.

Desktop environments

Solaris 2.4 (86Box) connected through Telnet on a virtual machine running Dell Unix. (also on 86Box)
Solaris 2.4 via Telnet
olvwm with OpenWindows on Solaris

Early releases of Solaris used OpenWindows as the standard desktop environment. In Solaris 2.0 to 2.2, OpenWindows supported both NeWS and X applications, and provided backward compatibility for SunView applications from Sun's older desktop environment. NeWS allowed applications to be built in an object-oriented way using PostScript, a common printing language released in 1982. The X Window System originated from MIT's Project Athena in 1984 and allowed for the display of an application to be disconnected from the machine where the application was running, separated by a network connection. Sun's original bundled SunView application suite was ported to X.

Sun later dropped support for legacy SunView applications and NeWS with OpenWindows 3.3, which shipped with Solaris 2.3, and switched to X11R5 with Display Postscript support. The graphical look and feel remained based upon OPEN LOOK. OpenWindows 3.6.2 was the last release under Solaris 8. The OPEN LOOK Window Manager (olwm) with other OPEN LOOK specific applications were dropped in Solaris 9, but support libraries were still bundled, providing long term binary backwards compatibility with existing applications. The OPEN LOOK Virtual Window Manager (olvwm) can still be downloaded for Solaris from sunfreeware and works on releases as recent as Solaris 10.

The Common Desktop Environment (CDE) was open sourced in August 2012. This is a screenshot of CDE running on Solaris 10.

Sun and other Unix vendors created an industry alliance to standardize Unix desktops. As a member of the Common Open Software Environment (COSE) initiative, Sun helped co-develop the Common Desktop Environment (CDE). This was an initiative to create a standard Unix desktop environment. Each vendor contributed different components: Hewlett-Packard contributed the window manager, IBM provided the file manager, and Sun provided the e-mail and calendar facilities as well as drag-and-drop support (ToolTalk). This new desktop environment was based upon the Motif look and feel and the old OPEN LOOK desktop environment was considered legacy. CDE unified Unix desktops across multiple open system vendors. CDE was available as an unbundled add-on for Solaris 2.4 and 2.5, and was included in Solaris 2.6 through 10.

Screenshot of the Java Desktop System (JDS) running on Solaris 10

In 2001, Sun issued a preview release of the open-source desktop environment GNOME 1.4, based on the GTK+ toolkit, for Solaris 8. Solaris 9 8/03 introduced GNOME 2.0 as an alternative to CDE. Solaris 10 includes Sun's Java Desktop System (JDS), which is based on GNOME and comes with a large set of applications, including StarOffice, Sun's office suite. Sun describes JDS as a "major component" of Solaris 10. The Java Desktop System is not included in Solaris 11 which instead ships with a stock version of GNOME. Likewise, CDE applications are no longer included in Solaris 11, but many libraries remain for binary backwards compatibility.

The open source desktop environments KDE and Xfce, along with numerous other window managers, also compile and run on recent versions of Solaris.

Sun was investing in a new desktop environment called Project Looking Glass since 2003. The project has been inactive since late 2006.

License

Traditional operating system license (1982 to 2004)

For versions up to 2005 (Solaris 9), Solaris was licensed under a license that permitted a customer to buy licenses in bulk, and install the software on any machine up to a maximum number. The key license grant was:

License to Use. Customer is granted a non-exclusive and non-transferable license ("License") for the use of the accompanying binary software in machine-readable form, together with accompanying documentation ("Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid.

In addition, the license provided a "License to Develop" granting rights to create derivative works, restricted copying to only a single archival copy, disclaimer of warranties, and the like. The license varied only little through 2004.

Open source (2005 until March 2010)

From 2005–10, Sun began to release the source code for development builds of Solaris under the Common Development and Distribution License (CDDL) via the OpenSolaris project. This code was based on the work being done for the post-Solaris 10 release (code-named "Nevada"; eventually released as Oracle Solaris 11). As the project progressed, it grew to encompass most of the necessary code to compile an entire release, with a few exceptions.

Post-Sun closed source (March 2010 to present)

When Sun was acquired by Oracle in 2010, the OpenSolaris project was discontinued after the board became unhappy with Oracle's stance on the project. In March 2010, the previously freely available Solaris 10 was placed under a restrictive license that limited the use, modification and redistribution of the operating system. The license allowed the user to download the operating system free of charge, through the Oracle Technology Network, and use it for a 90-day trial period. After that trial period had expired the user would then have to purchase a support contract from Oracle to continue using the operating system.

With the release of Solaris 11 in 2011, the license terms changed again. The new license allows Solaris 10 and Solaris 11 to be downloaded free of charge from the Oracle Technology Network and used without a support contract indefinitely; however, the license only expressly permits the user to use Solaris as a development platform and expressly forbids commercial and "production" use. Educational use is permitted in some circumstances. From the OTN license:

If You are an educational institution vested with the power to confer official high school, associate, bachelor, master and/or doctorate degrees, or local equivalent, ("Degree(s)"), You may also use the Programs as part of Your educational curriculum for students enrolled in Your Degree program(s) solely as required for the conferral of such Degree (collectively "Educational Use").

When Solaris is used without a support contract it can be upgraded to each new "point release"; however, a support contract is required for access to patches and updates that are released monthly.

Version history

Solaris logo used until Solaris 9
Solaris logo introduced with Solaris 10 and used until Oracle's acquisition of Sun

Notable features of Solaris include DTrace, Doors, Service Management Facility, Solaris Containers, Solaris Multiplexed I/O, Solaris Volume Manager, ZFS, and Solaris Trusted Extensions.

Updates to Solaris versions are periodically issued. In the past, these were named after the month and year of their release, such as "Solaris 10 1/13"; as of Solaris 11, sequential update numbers are appended to the release name with a period, such as "Oracle Solaris 11.4".

In ascending order, the following versions of Solaris have been released:


Legend: Old version, not maintained Older version, still maintained Current stable version
Solaris version SunOS version Release date End of support Basis License form Major new features
SPARC x86 SPARC/x86
1.x 4.1.x 1991–1994 September 2003 4.3BSD Traditional license SunOS 4 rebranded as Solaris 1 for marketing purposes. See SunOS article for more information.
2.0 5.0 June 1992 January 1999 SVR4 Traditional license Preliminary release (primarily available to developers only), support for only the sun4c architecture. First appearance of NIS+.
2.1 5.1 December 1992 May 1993 April 1999 SVR4 Traditional license Support for sun4 and sun4m architectures added; first Solaris x86 release. First Solaris 2 release to support SMP.
2.2 5.2 May 1993 May 1999 SVR4 Traditional license SPARC-only release. First to support sun4d architecture. First to support multithreading libraries (UI threads API in libthread).
2.3 5.3 November 1993 June 2002 SVR4 Traditional license SPARC-only release. OpenWindows 3.3 switches from NeWS to Display PostScript and drops SunView support. Support added for autofs and CacheFS filesystems.
2.4 5.4 November 1994 September 2003 SVR4 Traditional license First unified SPARC/x86 release. Includes OSF/Motif runtime support.
2.5 5.5 November 1995 December 2003 SVR4 Traditional license First to support UltraSPARC and include CDE, NFSv3 and NFS/TCP. Dropped sun4 (VMEbus) support. POSIX.1c-1995 pthreads added. Doors added but undocumented.
2.5.1 5.5.1 May 1996 September 2005 SVR4 Traditional license The only Solaris release that supports PowerPC; Ultra Enterprise support added; user and group IDs (uid_t, gid_t) expanded to 32 bits, also included processor sets and early resource management technologies.
2.6 5.6 July 1997 July 2006 SVR4 Traditional license Includes Kerberos 5, PAM, TrueType fonts, WebNFS, large file support, enhanced procfs. SPARCserver 600MP series support dropped. Last update was Solaris 2.6 5/98.
7 5.7 November 1998 August 2008 SVR4 Traditional license The first 64-bit UltraSPARC release. Added native support for file system meta-data logging (UFS logging). Dropped MCA support on x86 platform. Sun dropped the prefix "2." in the Solaris version number, leaving "Solaris 7". Last update was Solaris 7 11/99.
8 5.8 February 2000 March 2012 SVR4 Traditional license Includes Multipath I/O, Solstice DiskSuite, IPMP, first support for IPv6 and IPsec (manual keying only), mdb Modular Debugger. Introduced Role-Based Access Control (RBAC); sun4c support removed. Last update is Solaris 8 2/04.
9 5.9 May 28, 2002 January 10, 2003 October 2014 SVR4 Traditional license iPlanet Directory Server, Resource Manager, extended file attributes, IKE IPsec keying, and Linux compatibility added; OpenWindows dropped, sun4d support removed. Most current update is Solaris 9 9/05 HW.
10 5.10 January 31, 2005; 18 years ago January 2027 SVR4 before Oracle acquisition in March 2010, open source under CDDL

after March 2010, Post-Oracle closed source
Includes x86-64 (AMD64/Intel 64) support, DTrace (Dynamic Tracing), Solaris Containers, Service Management Facility (SMF) which replaces init.d scripts, NFSv4. Least privilege security model. Support for sun4m and UltraSPARC I processors removed. Support for EISA-based PCs removed. Adds Java Desktop System (based on GNOME) as default desktop.
  • Solaris 10 1/06 (known internally as "U1") added the GRUB bootloader for x86 systems, iSCSI Initiator support and fcinfo command-line tool.
  • Solaris 10 6/06 ("U2") added the ZFS filesystem.
  • Solaris 10 11/06 ("U3") added Solaris Trusted Extensions and Logical Domains (sun4v).
  • Solaris 10 8/07 ("U4") added Samba Active Directory support, IP Instances (part of the OpenSolaris Network Virtualization and Resource Control project), iSCSI Target support and Solaris Containers for Linux Applications (based on branded zones), enhanced version of the Resource Capping Daemon (rcapd).
  • Solaris 10 5/08 ("U5") added CPU capping for Solaris Containers, performance improvements, SpeedStep support for Intel processors and PowerNow! support for AMD processors.
  • Solaris 10 10/08 ("U6") added boot from ZFS and can use ZFS as its root file system. Solaris 10 10/08 also includes virtualization enhancements including the ability for a Solaris Container to automatically update its environment when moved from one system to another, Logical Domains support for dynamically reconfigurable disk and network I/O, and paravirtualization support when Solaris 10 is used as a guest OS in Xen-based environments such as Sun xVM Server.
  • Solaris 10 5/09 ("U7") added performance and power management support for Intel Nehalem processors, container cloning using ZFS cloned file systems, and performance enhancements for ZFS on solid-state drives.
  • Solaris 10 10/09 ("U8") added user and group level ZFS quotas, ZFS cache devices and nss_ldap shadowAccount Support, improvements to patching performance.
  • Solaris 10 9/10 ("U9") added physical to zone migration, ZFS triple parity RAID-Z and Oracle Solaris Auto Registration.
  • Solaris 10 8/11 ("U10") added ZFS speedups and new features, Oracle Database optimization, faster reboot on SPARC system.
  • Solaris 10 1/13 ("U11") see release notes.
11 Express 2010.11 5.11 November 15, 2010; 13 years ago November 2011 SVR4 Post-Oracle closed source Adds new packaging system (IPS – Image Packaging System) and associated tools, ZFS (only) for boot, 1 GB RAM min., x86, Solaris 10 Containers, network virtualization and quality of service (QoS), virtual consoles, ZFS encryption and deduplication, fast reboot, updated GNOME. Removed Xsun, CDE, and the /usr/ucb BSD-compatible commands
11 5.11 November 9, 2011; 12 years ago ? SVR4 Post-Oracle closed source New features and enhancements (compared to Solaris 10) in software packaging, network virtualization, server virtualization, storage, security and hardware support:
  • Packaging: Image Packaging System, network and local package repositories; Automated Installer to automated provisioning, including Zones; Distro Constructor to create ISO 9660 filesystem images;
  • Network: network virtualization (vNICs, vSwitches, vRouters) and QoS, Exclusive–IP default for Zones, the dladm utility to manage data links, the ipadm utility to manage IP configuration (including IPMP), ProFTPD and enhancements;
  • Zones: Immutable (read–only) Zones, NFS servers in zones, delegated administration, P2V pre–flight check, the zonestat utility coupled with the libzonestat dynamically linked library;
  • Security: root as a role, netcat and enhancements;
  • Storage: ZFS shadow migration, ZFS backup/restore with NDMP, recursive ZFS send;
  • Hardware support: SPARC T4, critical threads, SDP enabled and optimized, including support for Zones, SR-IOV, Intel AVX;
  • UEFI Boot support (Solaris 11.1 onwards on x86)
  • UltraSPARC II, III, IV series support removed; IA-32 architecture support removed.
11.1 5.11 October 3, 2012; 11 years ago ? SVR4 Post-Oracle closed source New features and enhancements:
11.2 5.11 April 29, 2014; 9 years ago ? SVR4 Post-Oracle closed source New features and enhancements:
11.3 5.11 October 26, 2015; 8 years ago January 2027 SVR4 Post-Oracle closed source New features and enhancements:
  • Live migration of Solaris Kernel Zones
  • InfiniBand support for Kernel Zones
  • Virtual Clocks for Solaris Zones
  • ZFS LZ4
  • SMB 2.1
  • Private VLAN
  • VNICs on IPoIB
  • Periodic and Scheduled Services
  • Tailored Compliance Reporting
  • OpenBSD 5.5 Packet Filter
  • Deferred Dump
  • Integration with OpenStack Juno
11.4 5.11 August 28, 2018; 5 years ago November 2034 SVR4 Post-Oracle closed source New features and enhancements:
  • CPUs with OSA2011 architecture required (UltraSPARC T4, SPARC64 X, or better)
  • ZFS Top-Level Device Removal. zpool remove
  • Solaris Web Dashboard and Analytics (sstore)
  • Native Zones: Live Zone Reconfiguration for Datasets
  • GNOME 3 instead of the GNOME 2 desktop

A more comprehensive summary of some Solaris versions is also available. Solaris releases are also described in the Solaris 2 FAQ.

Development release

The underlying Solaris codebase has been under continuous development since work began in the late 1980s on what was eventually released as Solaris 2.0. Each version such as Solaris 10 is based on a snapshot of this development codebase, taken near the time of its release, which is then maintained as a derived project. Updates to that project are built and delivered several times a year until the next official release comes out.

The Solaris version under development by Sun since the release of Solaris 10 in 2005, was codenamed Nevada, and is derived from what is now the OpenSolaris codebase.

In 2003, an addition to the Solaris development process was initiated. Under the program name Software Express for Solaris (or just Solaris Express), a binary release based on the current development basis was made available for download on a monthly basis, allowing anyone to try out new features and test the quality and stability of the OS as it progressed to the release of the next official Solaris version. A later change to this program introduced a quarterly release model with support available, renamed Solaris Express Developer Edition (SXDE).

In 2007, Sun announced Project Indiana with several goals, including providing an open source binary distribution of the OpenSolaris project, replacing SXDE. The first release of this distribution was OpenSolaris 2008.05.

The Solaris Express Community Edition (SXCE) was intended specifically for OpenSolaris developers. It was updated every two weeks until it was discontinued in January 2010, with a recommendation that users migrate to the OpenSolaris distribution. Although the download license seen when downloading the image files indicates its use is limited to personal, educational and evaluation purposes, the license acceptance form displayed when the user actually installs from these images lists additional uses including commercial and production environments.

SXCE releases terminated with build 130 and OpenSolaris releases terminated with build 134 a few weeks later. The next release of OpenSolaris based on build 134 was due in March 2010, but it was never fully released, though the packages were made available on the package repository. Instead, Oracle renamed the binary distribution Solaris 11 Express, changed the license terms and released build 151a as 2010.11 in November 2010.

Open source derivatives

Current

  • illumos – A fully open source fork of the project, started in 2010 by a community of Sun OpenSolaris engineers and Nexenta OS. OpenSolaris was not 100% open source: Some drivers and some libraries were property of other companies that Sun (now Oracle) licensed and was not able to release.
  • OpenIndiana – A project under the illumos umbrella aiming "... to become the de facto OpenSolaris distribution installed on production servers where security and bug fixes are required free of charge."
  • SchilliX – The first LiveCD released after OpenSolaris code was opened to public.
  • napp-it – A webmanaged ZFS storage appliance based on Solaris and the free forks like OmniOS with a Free and Pro edition.
  • NexentaStor – Optimized for storage workloads, based on Nexenta OS.
  • SmartOS – Virtualization centered derivative from MNX Solutions (previously Joyent).

Discontinued

  • OpenSolaris – A project initiated by Sun Microsystems, discontinued after the acquisition by Oracle.
  • Nexenta OS (discontinued October 31, 2012) – First distribution based on Ubuntu userland with Solaris-derived kernel.
  • StormOS (discontinued September 14, 2012) – A lightweight desktop OS based on Nexenta OS and Xfce.
  • MartUX – The first SPARC distribution of OpenSolaris, with an alpha prototype released by Martin Bochnig in April 2006. It was distributed as a Live CD but is later available only on DVD as it has had the Blastwave community software added. Its goal was to become a desktop operating system. The first SPARC release was a small Live CD, released as marTux_0.2 Live CD in summer of 2006, the first straight OpenSolaris distribution for SPARC (not to be confused with GNOME metacity theme). It was later re-branded as MartUX and the next releases included full SPARC installers in addition to the Live media. Much later, MartUX was re-branded as OpenSXCE when it moved to the first OpenSolaris release to support both SPARC and Intel architectures after Sun was acquired by Oracle.
  • MilaX – A small Live CD/Live USB with minimal set of packages to fit a 90 MB image.
  • Dyson – illumos kernel with GNU userland and packages from Debian. Project is no longer active and the website is offline.
  • EON ZFS Storage – A NAS implementation targeted at embedded systems.
  • Jaris OS – Live DVD and also installable. Pronounced according to the IPA but in English as Yah-Rees. This distribution has been heavily modified to fully support a version of Wine called Madoris that can install and run Windows programs at native speed. Jaris stands for "Japanese Solaris". Madoris is a combination of the Japanese word for Windows "mado" and Solaris.
  • OpenSXCE – An OpenSolaris distribution release for both 32-bit and 64-bit x86 platforms and SPARC microprocessors, initially produced from OpenSolaris source code repository, ported to the illumos source code repository to form OpenIndiana's first SPARC distribution. Notably, the first OpenSolaris distribution with illumos source for SPARC based upon OpenIndiana, OpenSXCE finally moved to a new source code repository, based upon DilOS.

Reception

  • Robert Lipschutz and Gregg Harrington from PC Magazine reviewed Solaris 9 in 2002:

All in all, Sun has stayed the course with Solaris 9. While its more user-friendly management is welcome, that probably won't be enough to win over converts. What may is the platform's reliability, flexibility, and power.

  • Robert Lipschutz also reviewed Solaris 10:

Be that as it may, since the Solaris 10 download is free, it behooves any IT manager to load it on an extra server and at least give it a try.

Solaris 10 provides a flexible background for securely dividing system resources, providing performance guarantees and tracking usage for these containers. Creating basic containers and populating them with user applications and resources is simple. But some cases may require quite a bit of fine-tuning.

I think that Sun has put some really nice touches on Solaris 10 that make it a better operating system for both administrators and users. The security enhancements are a long time coming, but are worth the wait. Is Solaris 10 perfect, in a word no it is not. But for most uses, including a desktop OS I think Solaris 10 is a huge improvement over previous releases.

We've had fun with Solaris 10. It's got virtues that we definitely admire. What it needs to compete with Linux will be easier to bring about than what it's already got. It could become a Linux killer, or at least a serious competitor on Linux's turf. The only question is whether Sun has the will to see it through.

System call

From Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/System_call

A high-level overview of the Linux kernel's system call interface, which handles communication between its various components and the userspace

In computing, a system call (commonly abbreviated to syscall) is the programmatic way in which a computer program requests a service from the operating system on which it is executed. This may include hardware-related services (for example, accessing a hard disk drive or accessing the device's camera), creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

In most systems, system calls can only be made from userspace processes, while in some systems, OS/360 and successors for example, privileged system code also issues system calls.

Privileges

The architecture of most modern processors, with the exception of some embedded systems, involves a security model. For example, the rings model specifies multiple privilege levels under which software may be executed: a program is usually limited to its own address space so that it cannot access or modify other running programs or the operating system itself, and is usually prevented from directly manipulating hardware devices (e.g. the frame buffer or network devices).

However, many applications need access to these components, so system calls are made available by the operating system to provide well-defined, safe implementations for such operations. The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often initiated via interrupts. An interrupt automatically puts the CPU into some elevated privilege level and then passes control to the kernel, which determines whether the calling program should be granted the requested service. If the service is granted, the kernel executes a specific set of instructions over which the calling program has no direct control, returns the privilege level to that of the calling program, and then returns control to the calling program.

The library as an intermediary

Generally, systems provide a library or API that sits between normal programs and the operating system. On Unix-like systems, that API is usually part of an implementation of the C library (libc), such as glibc, that provides wrapper functions for the system calls, often named the same as the system calls they invoke. On Windows NT, that API is part of the Native API, in the ntdll.dll library; this is an undocumented API used by implementations of the regular Windows API and directly used by some system programs on Windows. The library's wrapper functions expose an ordinary function calling convention (a subroutine call on the assembly level) for using the system call, as well as making the system call more modular. Here, the primary function of the wrapper is to place all the arguments to be passed to the system call in the appropriate processor registers (and maybe on the call stack as well), and also setting a unique system call number for the kernel to call. In this way the library, which exists between the OS and the application, increases portability.

The call to the library function itself does not cause a switch to kernel mode and is usually a normal subroutine call (using, for example, a "CALL" assembly instruction in some Instruction set architectures (ISAs)). The actual system call does transfer control to the kernel (and is more implementation-dependent and platform-dependent than the library call abstracting it). For example, in Unix-like systems, fork and execve are C library functions that in turn execute instructions that invoke the fork and exec system calls. Making the system call directly in the application code is more complicated and may require embedded assembly code to be used (in C and C++), as well as requiring knowledge of the low-level binary interface for the system call operation, which may be subject to change over time and thus not be part of the application binary interface; the library functions are meant to abstract this away.

On exokernel based systems, the library is especially important as an intermediary. On exokernels, libraries shield user applications from the very low level kernel API, and provide abstractions and resource management.

IBM's OS/360, DOS/360 and TSS/360 implement most system calls through a library of assembly language macros,[b] although there are a few services with a call linkage. This reflects their origin at a time when programming in assembly language was more common than high-level language usage. IBM system calls were therefore not directly executable by high-level language programs, but required a callable assembly language wrapper subroutine. Since then, IBM has added many services that can be called from high level languages in, e.g., z/OS and z/VSE. In more recent release of MVS/SP and in all later MVS versions, some system call macros generate Program Call (PC).

Examples and tools

On Unix, Unix-like and other POSIX-compliant operating systems, popular system calls are open, read, write, close, wait, exec, fork, exit, and kill. Many modern operating systems have hundreds of system calls. For example, Linux and OpenBSD each have over 300 different calls, NetBSD has close to 500, FreeBSD has over 500, Windows has close to 2000, divided between win32k (graphical) and ntdll (core) system calls while Plan 9 has 51.

Tools such as strace, ftrace and truss allow a process to execute from start and report all system calls the process invokes, or can attach to an already running process and intercept any system call made by the said process if the operation does not violate the permissions of the user. This special ability of the program is usually also implemented with system calls such as ptrace or system calls on files in procfs.

Typical implementations

Implementing system calls requires a transfer of control from user space to kernel space, which involves some sort of architecture-specific feature. A typical way to implement this is to use a software interrupt or trap. Interrupts transfer control to the operating system kernel, so software simply needs to set up some register with the system call number needed, and execute the software interrupt.

This is the only technique provided for many RISC processors, but CISC architectures such as x86 support additional techniques. For example, the x86 instruction set contains the instructions SYSCALL/SYSRET and SYSENTER/SYSEXIT (these two mechanisms were independently created by AMD and Intel, respectively, but in essence they do the same thing). These are "fast" control transfer instructions that are designed to quickly transfer control to the kernel for a system call without the overhead of an interrupt. Linux 2.5 began using this on the x86, where available; formerly it used the INT instruction, where the system call number was placed in the EAX register before interrupt 0x80 was executed.

An older mechanism is the call gate; originally used in Multics and later, for example, see call gate on the Intel x86. It allows a program to call a kernel function directly using a safe control transfer mechanism, which the operating system sets up in advance. This approach has been unpopular on x86, presumably due to the requirement of a far call (a call to a procedure located in a different segment than the current code segment) which uses x86 memory segmentation and the resulting lack of portability it causes, and the existence of the faster instructions mentioned above.

For IA-64 architecture, EPC (Enter Privileged Code) instruction is used. The first eight system call arguments are passed in registers, and the rest are passed on the stack.

In the IBM System/360 mainframe family, and its successors, a Supervisor Call instruction (SVC), with the number in the instruction rather than in a register, implements a system call for legacy facilities in most of[c] IBM's own operating systems, and for all system calls in Linux. In later versions of MVS, IBM uses the Program Call (PC) instruction for many newer facilities. In particular, PC is used when the caller might be in Service Request Block (SRB) mode.

The PDP-11 minicomputer used the EMT, TRAP and IOT instructions, which, similar to the IBM System/360 SVC and x86 INT, put the code in the instruction; they generate interrupts to specific addresses, transferring control to the operating system. The VAX 32-bit successor to the PDP-11 series used the CHMK, CHME, and CHMS instructions to make system calls to privileged code at various levels; the code is an argument to the instruction.

Categories of system calls

System calls can be grouped roughly into six major categories:


  1. Process control
  2. File management
    • create file, delete file
    • open, close
    • read, write, reposition
    • get/set file attributes
  3. Device management
    • request device, release device
    • read, write, reposition
    • get/set device attributes
    • logically attach or detach devices
  4. Information maintenance
    • get/set total system information (including time, date, computer name, enterprise etc.)
    • get/set process, file, or device metadata (including author, opener, creation time and date, etc.)
  5. Communication
    • create, delete communication connection
    • send, receive messages
    • transfer status information
    • attach or detach remote devices
  6. Protection
    • get/set file permissions

Processor mode and context switching

System calls in most Unix-like systems are processed in kernel mode, which is accomplished by changing the processor execution mode to a more privileged one, but no process context switch is necessary – although a privilege context switch does occur. The hardware sees the world in terms of the execution mode according to the processor status register, and processes are an abstraction provided by the operating system. A system call does not generally require a context switch to another process; instead, it is processed in the context of whichever process invoked it.[13][14]

In a multithreaded process, system calls can be made from multiple threads. The handling of such calls is dependent on the design of the specific operating system kernel and the application runtime environment. The following list shows typical models followed by operating systems:[15][16]

  • Many-to-one model: All system calls from any user thread in a process are handled by a single kernel-level thread. This model has a serious drawback – any blocking system call (like awaiting input from the user) can freeze all the other threads. Also, since only one thread can access the kernel at a time, this model cannot utilize multiple cores of processors.
  • One-to-one model: Every user thread gets attached to a distinct kernel-level thread during a system call. This model solves the above problem of blocking system calls. It is found in all major Linux distributions, macOS, iOS, recent Windows and Solaris versions.
  • Many-to-many model: In this model, a pool of user threads is mapped to a pool of kernel threads. All system calls from a user thread pool are handled by the threads in their corresponding kernel thread pool.
  • Hybrid model: This model implements both many to many and one to one models depending upon the choice made by the kernel. This is found in old versions of IRIX, HP-UX and Solaris.

Linux kernel interfaces

From Wikipedia, the free encyclopedia
Linux API, Linux ABI, and in-kernel APIs and ABIs

The Linux kernel provides multiple interfaces to user-space applications that are used for varying purposes and that have varying properties by design. There are two types of application programming interface (API) in the Linux kernel

  1. the "kernel–user space" API; and
  2. the "kernel internal" API.

Linux API

The Linux API is composed out of the System Call Interface of the Linux kernel, the GNU C Library (by GNU), libcgroup, libdrm, libalsa and libevdev (by freedesktop.org).
Linux API vs. POSIX API

The Linux API is the kernel–user space API, which allows programs in user space to access system resources and services of the Linux kernel. It is composed out of the System Call Interface of the Linux kernel and the subroutines in the GNU C Library (glibc). The focus of the development of the Linux API has been to provide the usable features of the specifications defined in POSIX in a way which is reasonably compatible, robust and performant, and to provide additional useful features not defined in POSIX, just as the kernel–user space APIs of other systems implementing the POSIX API also provide additional features not defined in POSIX.

The Linux API, by choice, has been kept stable over the decades through a policy of not introducing breaking changes; this stability guarantees the portability of source code. At the same time, Linux kernel developers have historically been conservative and meticulous about introducing new system calls.

Much available free and open-source software is written for the POSIX API. Since so much more development flows into the Linux kernel as compared to the other POSIX-compliant combinations of kernel and C standard library, the Linux kernel and its API have been augmented with additional features. As far as these additional features provide a technical advantage, programming for the Linux API is preferred over the POSIX-API. Well-known current examples are udev, systemd and Weston. People such as Lennart Poettering openly advocate to prefer the Linux API over the POSIX API, where this offers advantages.

At FOSDEM 2016, Michael Kerrisk explained some of the perceived issues with the Linux kernel's user-space API, describing that it contains multiple design errors by being non-extensible, unmaintainable, overly complex, of limited purpose, in violation of standards, and inconsistent. Most of those mistakes cannot be fixed because doing so would break the ABI that the kernel presents to the user space.

System Call Interface of the Linux kernel

System Call Interface is the denomination for the entirety of all implemented and available system calls in a kernel. Various subsystems, such as the Direct Rendering Manager (DRM), define their own system calls and the entirety is called System Call Interface.

Various issues with the organization of the Linux kernel system calls are being publicly discussed. Issues have been pointed out by Andy Lutomirski, Michael Kerrisk and others.

The C standard library

The GNU C Library is a wrapper around the Linux kernel System Call Interface.

A C standard library is a wrapper around the system calls of the Linux kernel; the combination of the Linux kernel System Call Interface and a C standard library is what builds the Linux API. Some popular implementations of the C standard library are

Additions to POSIX

As in other Unix-like systems, additional capabilities of the Linux kernel exist that are not part of POSIX:

DRM has been paramount for the development and implementations of well-defined and performant free and open-source graphics device drivers without which no rendering acceleration would be available at all, only the 2D drivers would be available in the X.Org Server. DRM was developed for Linux, and since has been ported to other operating systems as well.

Further libraries

Linux ABI

The Linux API and the Linux ABI

The term Linux ABI refers to a kernel–user space ABI. The application binary interface refers to the compiled binaries, in machine code. Any such ABI is therefore bound to the instruction set. Defining a useful ABI and keeping it stable is less the responsibility of the Linux kernel developers or of the developers of the GNU C Library, and more the task for Linux distributions and independent software vendors (ISVs) who wish to sell and provide support for their proprietary software as binaries only for such a single Linux ABI, as opposed to supporting multiple Linux ABIs.

An ABI has to be defined for every instruction set, such as x86, x86-64, MIPS, ARMv7-A (32-Bit), ARMv8-A (64-Bit), etc. with the endianness, if both are supported.

It should be able to compile the software with different compilers against the definitions specified in the ABI and achieve full binary compatibility. Compilers that are free and open-source software are e.g. GNU Compiler Collection, LLVM/Clang.

In-kernel APIs

There are a lot of kernel-internal APIs for all the subsystems to interface with one another. These are being kept fairly stable, but there is no guarantee for stability. In case new research or insights make a change seem favorable, an API is changed, all necessary rewrite and testing have to be done by the author.

The Linux kernel is a monolithic kernel, hence device drivers are kernel components. To ease the burden of companies maintaining their (proprietary) device drivers out-of-tree, stable APIs for the device drivers have been repeatedly requested. The Linux kernel developers have repeatedly denied guaranteeing stable in-kernel APIs for device drivers. Guaranteeing such would have faltered the development of the Linux kernel in the past and would still in the future and, due to the nature of free and open-source software, are not necessary. Ergo, by choice, the Linux kernel has no stable in-kernel API.

In-kernel ABIs

Since there are no stable in-kernel APIs, there cannot be stable in-kernel ABIs.

Abstraction APIs

OpenGL is indeed an abstraction API to make use of diverse GPUs of multiple vendors without the need to program for each one specifically.
But the implementation of the OpenGL-specification is executed on the CPU in the context of the running operating system. One design goal of Vulkan was to make the "graphics driver", i.e. the implementation of the graphics API, do less.

For several use cases, the Linux API is considered too low-level and higher abstraction APIs are used. Such of course still need to work on top of the low-level Linux APIs. Examples:

Romance (love)

From Wikipedia, the free encyclopedia https://en.wikipedia.org/w...