Editing Operating system (section)

===Library===
A ''library operating system'' (libOS) is one in which the services that a typical operating system provides, such as networking, are provided in the form of [[Library (computing)|libraries]] and composed with a single application and configuration code to construct a [[unikernel]]:
<ref name="Unikernels">{{cite magazine
 |last1=Madhavapeddy |first1=Anil
 |last2=Scott |first2=David J
 |date=November 2013
 |title=Unikernels: Rise of the Virtual Library Operating System: What if all the software layers in a virtual appliance were compiled within the same safe, high-level language framework?
 |magazine=Queue |volume=11 |issue=11
 |pages=30–44
 |location=New York, NY, USA
 |publisher=ACM
 |issn=1542-7730
 |url=https://doi.org/10.1145/2557963.2566628
 |doi=10.1145/2557963.2566628
 |access-date=2024-08-07
}}</ref> a specialized (only the absolute necessary pieces of code are extracted from libraries and bound together
<ref name="Unikraft-Build-Process">{{cite web
 |url=https://unikraft.org/docs/concepts/build-process
 |access-date=2024-08-08
 |title=Build Process - Unikraft
 |archive-date=2024-04-22
 |archive-url=https://web.archive.org/web/20240422183734/https://unikraft.org/docs/concepts/build-process
 |url-status=live
}}</ref>), [[Single address space operating system|single address space]], machine image that can be deployed to cloud or embedded environments.

The operating system code and application code are not executed in separated [[Protection ring|protection domains]] (there is only a single application running, at least conceptually, so there is no need to prevent interference between applications) and OS services are accessed via simple library calls (potentially [[Inline expansion|inlining]] them based on compiler thresholds), without the usual overhead of [[context switch]]es,
<ref name="rise-of-libOS">{{cite web
 |url=https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/
 |access-date=2024-08-07
 |title=Leave your OS at home: the rise of library operating systems
 |date=2017-09-14
 |publisher=[[ACM SIGARCH]]
 |archive-date=2024-03-01
 |archive-url=https://web.archive.org/web/20240301072916/https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/
 |url-status=live
}}</ref> in a way similarly to embedded and real-time OSes. Note that this overhead is not negligible: to the direct cost of mode switching it's necessary to add the indirect pollution of important processor structures (like [[CPU cache]]s, the [[Instruction pipelining|instruction pipeline]], and so on) which affects both user-mode and kernel-mode performance.
<ref name="FlexSC">{{cite conference
 |url=https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls
 |title=FlexSC: Flexible System Call Scheduling with Exception-Less System Calls
 |last1=Soares |first1=Livio Baldini <!-- https://liviosoares.github.io/ -->
 |last2=Stumm  |first2=Michael       <!-- https://www.eecg.toronto.edu/~stumm/index.html -->
 |date=2010-10-04
 |conference=OSDI '10, 9th USENIX Symposium on Operating System Design and Implementation
 |conference-url=https://www.usenix.org/legacy/events/osdi10/
 |publisher=[[USENIX]]
 |access-date=2024-08-09
 |quote=Synchronous implementation of system calls negatively impacts the performance of system intensive workloads, both in terms of the ''direct'' costs of mode switching and, more interestingly, in terms of the ''indirect'' pollution of important processor structures which affects both user-mode and kernel-mode performance. A motivating example that quantifies the impact of system call pollution on application performance can be seen in Figure 1. It depicts the user-mode instructions per cycles (kernel cycles and instructions are ignored) of one of the SPEC CPU 2006 benchmarks (Xalan) immediately before and after a <code>pwrite</code> system call. There is a significant drop in instructions per cycle (IPC) due to the system call, and it takes up to 14,000 cycles of execution before the IPC of this application returns to its previous level. As we will show, this performance degradation is mainly due to interference caused by the kernel on key processor structures.
 |quote-page=2
}}</ref>