Source string Read only

(itstool) path: sect4/para

1028/10280
Context English State
<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
<literal>CLONE_SIGHAND</literal> - share signal handlers and blocked signals
<literal>CLONE_PARENT</literal> - share parent
<literal>CLONE_THREAD</literal> - be thread (further explanation below)
<literal>CLONE_NEWNS</literal> - new namespace
<literal>CLONE_SYSVSEM</literal> - share SysV undo structures
<literal>CLONE_SETTLS</literal> - setup TLS at supplied address
<literal>CLONE_PARENT_SETTID</literal> - set TID in the parent
<literal>CLONE_CHILD_CLEARTID</literal> - clear TID in the child
<literal>CLONE_CHILD_SETTID</literal> - set TID in the child
<literal>CLONE_PARENT</literal> sets the real parent to the parent of the caller. This is useful for threads because if thread A creates thread B we want thread B to be parented to the parent of the whole thread group. <literal>CLONE_THREAD</literal> does exactly the same thing as <literal>CLONE_PARENT</literal>, <literal>CLONE_VM</literal> and <literal>CLONE_SIGHAND</literal>, rewrites PID to be the same as PID of the caller, sets exit signal to be none and enters the thread group. <literal>CLONE_SETTLS</literal> sets up GDT entries for TLS handling. The <literal>CLONE_*_*TID</literal> set of flags sets/clears user supplied address to TID or 0.
As you can see the <literal>CLONE_THREAD</literal> does most of the work and does not seem to fit the scheme very well. The original intention is unclear (even for authors, according to comments in the code) but I think originally there was one threading flag, which was then parcelled among many other flags but this separation was never fully finished. It is also unclear what this partition is good for as glibc does not use that so only hand-written use of the clone permits a programmer to access this features.

Loading…

User avatar None

New source string

FreeBSD Doc / articles_linux-emulationEnglish

New source string 6 months ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment

(itstool) path: sect4/para

Flags
read-only
Source string location
article.translate.xml:571
String age
6 months ago
Source string age
6 months ago
Translation file
articles/linux-emulation.pot, string 87