Source string Read only

(itstool) path: sect3/para
480/4800
Context English State
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. Because of 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).
What is <trademark class="registered">Linux</trademark>
<trademark class="registered">Linux</trademark> is a <trademark class="registered">UNIX</trademark>-like kernel originally developed by Linus Torvalds, and now being contributed to by a massive crowd of programmers all around the world. From its mere beginnings to today, with wide support from companies such as IBM or Google, <trademark class="registered">Linux</trademark> is being associated with its fast development pace, full hardware support and benevolent dictator model of organization.
<trademark class="registered">Linux</trademark> development started in 1991 as a hobbyist project at University of Helsinki in Finland. Since then it has obtained all the features of a modern <trademark class="registered">UNIX</trademark>-like OS: multiprocessing, multiuser support, virtual memory, networking, basically everything is there. There are also highly advanced features like virtualization etc.
As of 2006 <trademark class="registered">Linux</trademark> seems to be the most widely used open source operating system with support from independent software vendors like Oracle, RealNetworks, Adobe, etc. Most of the commercial software distributed for <trademark class="registered">Linux</trademark> can only be obtained in a binary form so recompilation for other operating systems is impossible.
Most of the <trademark class="registered">Linux</trademark> development happens in a <application>Git</application> version control system. <application>Git</application> is a distributed system so there is no central source of the <trademark class="registered">Linux</trademark> code, but some branches are considered prominent and official. The version number scheme implemented by <trademark class="registered">Linux</trademark> consists of four numbers A.B.C.D. Currently development happens in 2.6.C.D, where C represents major version, where new features are added or changed while D is a minor version for bugfixes only.
More information can be obtained from [3].
<trademark class="registered">Linux</trademark> follows the traditional <trademark class="registered">UNIX</trademark> scheme of dividing the run of a process in two halves: the kernel and user space. The kernel can be entered in two ways: via a trap or via a syscall. The return is handled only in one way. The further description applies to <trademark class="registered">Linux</trademark> 2.6 on the <trademark>i386</trademark> architecture. This information was taken from [2].
Syscalls in <trademark class="registered">Linux</trademark> are performed (in userspace) using <literal>syscallX</literal> macros where X substitutes a number representing the number of parameters of the given syscall. This macro translates to a code that loads <varname>%eax</varname> register with a number of the syscall and executes interrupt <literal>0x80</literal>. After this syscall return is called, which translates negative return values to positive <literal>errno</literal> values and sets <literal>res</literal> to <literal>-1</literal> in case of an error. Whenever the interrupt <literal>0x80</literal> is called the process enters the kernel in system call trap handler. This routine saves all registers on the stack and calls the selected syscall entry. Note that the <trademark class="registered">Linux</trademark> calling convention expects parameters to the syscall to be passed via registers as shown here:
parameter -&gt; <varname>%ebx</varname>
parameter -&gt; <varname>%ecx</varname>
parameter -&gt; <varname>%edx</varname>
parameter -&gt; <varname>%esi</varname>
parameter -&gt; <varname>%edi</varname>
parameter -&gt; <varname>%ebp</varname>
There are some exceptions to this, where <trademark class="registered">Linux</trademark> uses different calling convention (most notably the <literal>clone</literal> syscall).
The trap handlers are introduced in <filename>arch/i386/kernel/traps.c</filename> and most of these handlers live in <filename>arch/i386/kernel/entry.S</filename>, where handling of the traps happens.
Return from the syscall is managed by syscall <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, which checks for the process having unfinished work, then checks whether we used user-supplied selectors. If this happens stack fixing is applied and finally the registers are restored from the stack and the process returns to the userspace.
In the 2.6 version, the <trademark class="registered">Linux</trademark> operating system redefined some of the traditional <trademark class="registered">UNIX</trademark> primitives, notably PID, TID and thread. PID is defined not to be unique for every process, so for some processes (threads) <citerefentry><refentrytitle>getppid</refentrytitle><manvolnum>2</manvolnum></citerefentry> returns the same value. Unique identification of process is provided by TID. This is because <firstterm>NPTL</firstterm> (New <trademark class="registered">POSIX</trademark> Thread Library) defines threads to be normal processes (so called 1:1 threading). Spawning a new process in <trademark class="registered">Linux</trademark> 2.6 happens using the <literal>clone</literal> syscall (fork variants are reimplemented using it). This clone syscall defines a set of flags that affect behavior of the cloning process regarding thread implementation. The semantic is a bit fuzzy as there is no single flag telling the syscall to create a thread.
Implemented clone flags are:
<literal>CLONE_VM</literal> - processes share their memory space
<literal>CLONE_FS</literal> - share umask, cwd and namespace
<literal>CLONE_FILES</literal> - share open files

Loading…

User avatar None

New source string

FreeBSD Doc / articles_linux-emulationEnglish

New source string 6 months ago
Browse all component changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Flags
read-only
Source string location
article.translate.xml:493
String age
6 months ago
Source string age
6 months ago
Translation file
articles/linux-emulation.pot, string 76