The translation is temporarily closed for contributions due to maintenance, please come back later.
English Portuguese (Brazil)
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. Nesta seção vamos descrever cada sistema operacional em questão. Como eles lidam com syscalls, trapframes etc., todo o material de baixo nível. Também descrevemos a maneira como eles entendem primitivas comuns <trademark class="registered">UNIX</trademark>, como o que é um PID, o que é uma thread, etc. Na terceira subseção, falamos sobre como <trademark class="registered">UNIX</trademark> em emuladores <trademark class="registered">UNIX</trademark> pode ser feita em geral.
What is <trademark class="registered">UNIX</trademark> O que é o <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. <trademark class="registered">UNIX</trademark> é um sistema operacional com um longo histórico que influenciou quase todos os outros sistemas operacionais atualmente em uso. Começando na década de 1960, seu desenvolvimento continua até hoje (embora em projetos diferentes). O desenvolvimento de <trademark class="registered">UNIX</trademark> logo se bifurcou em duas formas principais: as famílias BSDs e System III/V. Eles se influenciaram mutuamente ao desenvolver um padrão <trademark class="registered">UNIX</trademark> comum. Entre as contribuições originadas no BSD, podemos nomear memória virtual, rede TCP/IP, FFS e muitas outras. A ramificação SystemV contribuiu para as primitivas de comunicação entre processos SysV, copy-on-write, etc. <trademark class="registered">UNIX</trademark> em si não existe mais, mas suas idéias têm sido usadas por muitos outros sistemas operacionais amplos formando assim os chamados sistemas operacionais como <trademark class="registered">UNIX</trademark>. Hoje em dia os mais influentes são <trademark class="registered">Linux</trademark>, Solaris e possivelmente (até certo ponto) FreeBSD. Existem sistemas <trademark class="registered">UNIX</trademark> de companhias derivados como (AIX, HP-UX etc.), mas estas foram cada vez mais migrados para os sistemas acima mencionados. Vamos resumir as características típicas do <trademark class="registered">UNIX</trademark>.
Technical details Detalhes técnicos
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. Todo programa em execução constitui um processo que representa um estado da computação. O processo de execução é dividido entre o espaço do kernel e o espaço do usuário. Algumas operações podem ser feitas somente a partir do espaço do kernel (lidando com hardware, etc.), mas o processo deve passar a maior parte de sua vida útil no espaço do usuário. O kernel é onde o gerenciamento dos processos, hardware e detalhes de baixo nível acontecem. O kernel fornece uma API unificada padrão <trademark class="registered">UNIX</trademark> para o espaço do usuário. Os mais importantes são abordados abaixo.
Communication between kernel and user space process Comunicação entre o kernel e o processo de espaço do usuário
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. A API comum do <trademark class="registered">UNIX</trademark> define uma syscall como uma forma de emitir comandos de um processo do espaço do usuário para o kernel. A implementação mais comum é usando uma instrução de interrupção ou especializada (pense em instruções <literal>SYSENTER</literal>/<literal>SYSCALL</literal> para ia32). Syscalls são definidos por um número. Por exemplo, no FreeBSD, a syscall número 85 é a syscall <citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry> e a syscall número 132 é a syscall <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Algumas syscalls precisam de parâmetros, que são passados do espaço do usuário para o espaço do kernel de várias maneiras (dependente da implementação). Syscalls são síncronas.
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). Outra maneira possível de se comunicar é usando uma <firstterm>trap</firstterm>. As traps ocorrem de forma assíncrona após a ocorrência de algum evento (divisão por zero, falha de página, etc.). Uma trap pode ser transparente para um processo (falha de página) ou pode resultar em uma reação como o envio de um <firstterm>signal</firstterm> (divisão por zero).
Communication between processes Comunicação entre processos
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. Existem outras APIs (System V IPC, memória compartilhada, etc.), mas a API mais importante é o signal. Os signals são enviados por processos ou pelo kernel e recebidos por processos. Alguns signals podem ser ignorados ou manipulados por uma rotina fornecida pelo usuário, alguns resultam em uma ação predefinida que não pode ser alterada ou ignorada.
Process management Gerenciamento de processos
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). As instâncias do kernel são processadas primeiro no sistema (chamado init). Todo processo em execução pode criar sua cópia idêntica usando a syscall <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum> </citerefentry>. Algumas versões ligeiramente modificadas desta syscall foram introduzidas, mas a semântica básica é a mesma. Todo processo em execução pode se transformar em algum outro processo usando a syscall <citerefentry><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Algumas modificações desta syscall foram introduzidas, mas todas servem ao mesmo propósito básico. Os processos terminam suas vidas chamando a syscall <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Todo processo é identificado por um número único chamado PID. Todo processo tem um processo pai definido (identificado pelo seu PID).
Thread management Gerenciamento de threads
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: O <trademark class="registered">UNIX</trademark> tradicional não define nenhuma API nem implementação para threading, enquanto <trademark class="registered">POSIX</trademark> define sua API de threading, mas a implementação é indefinida. Tradicionalmente, havia duas maneiras de implementar threads. Manipulando-as como processos separados (threading 1:1) ou envolver todo o grupo de thread em um processo e gerenciando a threading no espaço do usuário (threading 1:N). Comparando as principais características de cada abordagem:
1:1 threading 1:1 threading
- heavyweight threads - threads pesadas
- the scheduling cannot be altered by the user (slightly mitigated by the <trademark class="registered">POSIX</trademark> API) - o agendamento não pode ser alterado pelo usuário (ligeiramente mitigado pela API <trademark class="registered"> POSIX </trademark>)
+ no syscall wrapping necessary + não necessita de envolvimento do syscall
+ can utilize multiple CPUs + pode utilizar várias CPUs
1:N threading 1: N threading