Source string Read only

(itstool) path: listitem/para
26/260
Context English State
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
FreeBSD/i386 emulation on FreeBSD/ia64
<trademark class="registered">Linux</trademark>-emulation of <trademark class="registered">Linux</trademark> operating system on FreeBSD
NDIS-emulation of Windows networking drivers interface
NetBSD-emulation of NetBSD operating system
PECoff-support for PECoff FreeBSD executables
SVR4-emulation of System V revision 4 <trademark class="registered">UNIX</trademark>
Actively developed emulations are the <trademark class="registered">Linux</trademark> layer and various FreeBSD-on-FreeBSD layers. Others are not supposed to work properly nor be usable these days.
FreeBSD is traditional flavor of <trademark class="registered">UNIX</trademark> in the sense of dividing the run of processes into two halves: kernel space and user space run. There are two types of process entry to the kernel: a syscall and a trap. There is only one way to return. In the subsequent sections we will describe the three gates to/from the kernel. The whole description applies to the i386 architecture as the Linuxulator only exists there but the concept is similar on other architectures. The information was taken from [1] and the source code.
System entries
FreeBSD has an abstraction called an execution class loader, which is a wedge into the <citerefentry><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. This employs a structure <literal>sysentvec</literal>, which describes an executable ABI. It contains things like errno translation table, signal translation table, various functions to serve syscall needs (stack fixup, coredumping, etc.). Every ABI the FreeBSD kernel wants to support must define this structure, as it is used later in the syscall processing code and at some other places. System entries are handled by trap handlers, where we can access both the kernel-space and the user-space at once.

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Flags
read-only
Source string location
article.translate.xml:248
String age
a year ago
Source string age
a year ago
Translation file
articles/linux-emulation.pot, string 43