The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: listitem/para
Context English State
+ 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.
Syscalls
Syscalls on FreeBSD are issued by executing interrupt <literal>0x80</literal> with register <varname>%eax</varname> set to a desired syscall number with arguments passed on the stack.
When a process issues an interrupt <literal>0x80</literal>, the <literal>int0x80</literal> syscall trap handler is issued (defined in <filename>sys/i386/i386/exception.s</filename>), which prepares arguments (i.e. copies them on to the stack) for a call to a C function <citerefentry><refentrytitle>syscall</refentrytitle><manvolnum>2</manvolnum></citerefentry> (defined in <filename>sys/i386/i386/trap.c</filename>), which processes the passed in trapframe. The processing consists of preparing the syscall (depending on the <literal>sysvec</literal> entry), determining if the syscall is 32-bit or 64-bit one (changes size of the parameters), then the parameters are copied, including the syscall. Next, the actual syscall function is executed with processing of the return code (special cases for <literal>ERESTART</literal> and <literal>EJUSTRETURN</literal> errors). Finally an <literal>userret()</literal> is scheduled, switching the process back to the users-pace. The parameters to the actual syscall handler are passed in the form of <literal>struct thread *td</literal>, <literal>struct syscall args *</literal> arguments where the second parameter is a pointer to the copied in structure of parameters.
Traps
Handling of traps in FreeBSD is similar to the handling of syscalls. Whenever a trap occurs, an assembler handler is called. It is chosen between alltraps, alltraps with regs pushed or calltrap depending on the type of the trap. This handler prepares arguments for a call to a C function <literal>trap()</literal> (defined in <filename>sys/i386/i386/trap.c</filename>), which then processes the occurred trap. After the processing it might send a signal to the process and/or exit to userland using <literal>userret()</literal>.
Exits
Exits from kernel to userspace happen using the assembler routine <literal>doreti</literal> regardless of whether the kernel was entered via a trap or via a syscall. This restores the program status from the stack and returns to the userspace.
<trademark class="registered">UNIX</trademark> primitives
FreeBSD operating system adheres to the traditional <trademark class="registered">UNIX</trademark> scheme, where every process has a unique identification number, the so called <firstterm>PID</firstterm> (Process ID). PID numbers are allocated either linearly or randomly ranging from <literal>0</literal> to <literal>PID_MAX</literal>. The allocation of PID numbers is done using linear searching of PID space. Every thread in a process receives the same PID number as result of the <citerefentry><refentrytitle>getpid</refentrytitle><manvolnum>2</manvolnum></citerefentry> call.
There are currently two ways to implement threading in FreeBSD. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (<literal>libpthread</literal>) and you can switch at runtime to 1:1 threading (<literal>libthr</literal>). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the <literal>kse_*</literal> family of syscalls while the 1:1 library uses the <literal>thr_*</literal> family of syscalls. Due to this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by <literal>struct thread</literal>) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on.
As stated previously there are two implementations of threading in FreeBSD. The M:N library divides the work between kernel space and userspace. Thread is an entity that gets scheduled in the kernel but it can represent various number of userspace threads. M userspace threads get mapped to N kernel threads thus saving resources while keeping the ability to exploit multiprocessor parallelism. Further information about the implementation can be obtained from the man page or [1]. The 1:1 library directly maps a userland thread to a kernel thread thus greatly simplifying the scheme. None of these designs implement a fairness mechanism (such a mechanism was implemented but it was removed recently because it caused serious slowdown and made the code more difficult to deal with).

Loading…

No matching activity found.

Browse all component changes

Source information

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