Source string Read only

(itstool) path: sect3/title
Context English State
Naturally, a need for the ability to run <trademark class="registered">Linux</trademark> binaries on a FreeBSD system arises and this is what this thesis deals with: the emulation of the <trademark class="registered">Linux</trademark> kernel in the FreeBSD operating system.
During the Summer of 2006 Google Inc. sponsored a project which focused on extending the <trademark class="registered">Linux</trademark> emulation layer (the so called Linuxulator) in FreeBSD to include <trademark class="registered">Linux</trademark> 2.6 facilities. This thesis is written as a part of this project.
A look inside…
In this section we are going to describe every operating system in question. How they deal with syscalls, trapframes etc., all the low-level stuff. We also describe the way they understand common <trademark class="registered">UNIX</trademark> primitives like what a PID is, what a thread is, etc. In the third subsection we talk about how <trademark class="registered">UNIX</trademark> on <trademark class="registered">UNIX</trademark> emulation could be done in general.
What is <trademark class="registered">UNIX</trademark>
<trademark class="registered">UNIX</trademark> is an operating system with a long history that has influenced almost every other operating system currently in use. Starting in the 1960s, its development continues to this day (although in different projects). <trademark class="registered">UNIX</trademark> development soon forked into two main ways: the BSDs and System III/V families. They mutually influenced themselves by growing a common <trademark class="registered">UNIX</trademark> standard. Among the contributions originated in BSD we can name virtual memory, TCP/IP networking, FFS, and many others. The System V branch contributed to SysV interprocess communication primitives, copy-on-write, etc. <trademark class="registered">UNIX</trademark> itself does not exist any more but its ideas have been used by many other operating systems world wide thus forming the so called <trademark class="registered">UNIX</trademark>-like operating systems. These days the most influential ones are <trademark class="registered">Linux</trademark>, Solaris, and possibly (to some extent) FreeBSD. There are in-company <trademark class="registered">UNIX</trademark> derivatives (AIX, HP-UX etc.), but these have been more and more migrated to the aforementioned systems. Let us summarize typical <trademark class="registered">UNIX</trademark> characteristics.
Technical details
Every running program constitutes a process that represents a state of the computation. Running process is divided between kernel-space and user-space. Some operations can be done only from kernel space (dealing with hardware etc.), but the process should spend most of its lifetime in the user space. The kernel is where the management of the processes, hardware, and low-level details take place. The kernel provides a standard unified <trademark class="registered">UNIX</trademark> API to the user space. The most important ones are covered below.
Communication between kernel and user space process
Common <trademark class="registered">UNIX</trademark> API defines a syscall as a way to issue commands from a user space process to the kernel. The most common implementation is either by using an interrupt or specialized instruction (think of <literal>SYSENTER</literal>/<literal>SYSCALL</literal> instructions for ia32). Syscalls are defined by a number. For example in FreeBSD, the syscall number 85 is the <citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall and the syscall number 132 is <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependant). Syscalls are synchronous.
Another possible way to communicate is by using a <firstterm>trap</firstterm>. Traps occur asynchronously after some event occurs (division by zero, page fault etc.). A trap can be transparent for a process (page fault) or can result in a reaction like sending a <firstterm>signal</firstterm> (division by zero).
Communication between processes
There are other APIs (System V IPC, shared memory etc.) but the single most important API is signal. Signals are sent by processes or by the kernel and received by processes. Some signals can be ignored or handled by a user supplied routine, some result in a predefined action that cannot be altered or ignored.
Process management
Kernel instances are processed first in the system (so called init). Every running process can create its identical copy using the <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Some slightly modified versions of this syscall were introduced but the basic semantic is the same. Every running process can morph into some other process using the <citerefentry><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry> syscall. Some modifications of this syscall were introduced but all serve the same basic purpose. Processes end their lives by calling the <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Every process is identified by a unique number called PID. Every process has a defined parent (identified by its PID).
Thread management
Traditional <trademark class="registered">UNIX</trademark> does not define any API nor implementation for threading, while <trademark class="registered">POSIX</trademark> defines its threading API but the implementation is undefined. Traditionally there were two ways of implementing threads. Handling them as separate processes (1:1 threading) or envelope the whole thread group in one process and managing the threading in userspace (1:N threading). Comparing main features of each approach:
1:1 threading
- heavyweight threads
- the scheduling cannot be altered by the user (slightly mitigated by the <trademark class="registered">POSIX</trademark> API)
+ no syscall wrapping necessary
+ can utilize multiple CPUs
1:N threading
+ lightweight threads
+ scheduling can be easily altered by the user
- syscalls must be wrapped
- cannot utilize more than one CPU
What is FreeBSD?
The FreeBSD project is one of the oldest open source operating systems currently available for daily use. It is a direct descendant of the genuine <trademark class="registered">UNIX</trademark> so it could be claimed that it is a true <trademark class="registered">UNIX</trademark> although licensing issues do not permit that. The start of the project dates back to the early 1990's when a crew of fellow BSD users patched the 386BSD operating system. Based on this patchkit a new operating system arose named FreeBSD for its liberal license. Another group created the NetBSD operating system with different goals in mind. We will focus on FreeBSD.
FreeBSD is a modern <trademark class="registered">UNIX</trademark>-based operating system with all the features of <trademark class="registered">UNIX</trademark>. Preemptive multitasking, multiuser facilities, TCP/IP networking, memory protection, symmetric multiprocessing support, virtual memory with merged VM and buffer cache, they are all there. One of the interesting and extremely useful features is the ability to emulate other <trademark class="registered">UNIX</trademark>-like operating systems. As of December 2006 and 7-CURRENT development, the following emulation functionalities are supported:
FreeBSD/i386 emulation on FreeBSD/amd64


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/title
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/linux-emulation.pot, string 33