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

Translation

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 ofDue 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.
(itstool) path: sect4/para
English
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.
Context English Portuguese (Brazil) State
PECoff-support for PECoff FreeBSD executables Suporte PECoff para executáveis PECoff do FreeBSD
SVR4-emulation of System V revision 4 <trademark class="registered">UNIX</trademark> Emulação SVR4 do <trademark class="registered">UNIX</trademark> System V revisão 4
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. Emulações ativamente desenvolvidas são a camada <trademark class="registered">Linux</trademark> e várias camadas FreeBSD-on-FreeBSD. Outros não devem funcionar corretamente nem ser utilizáveis nos dias de hoje.
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. O FreeBSD é o gostinho tradicional de <trademark class="registered">UNIX</trademark> no sentido de dividir a execução dos processos em duas metades: espaço do kernel e execução do espaço do usuário. Existem dois tipos de entrada de processo no kernel: uma syscall e uma trap. Há apenas uma maneira de retornar. Nas seções subseqüentes, descreveremos as três portas de/para o kernel. Toda a descrição se aplica à arquitetura i386, pois o Linuxulator só existe lá, mas o conceito é semelhante em outras arquiteturas. A informação foi retirada de [1] e do código fonte.
System entries Entradas do sistema
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. O FreeBSD tem uma abstração chamada loader de classes de execução, que é uma entrada na syscall <citerefentry><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Isto emprega uma estrutura <literal>sysentvec</literal>, que descreve uma ABI executável. Ele contém coisas como tabela de tradução de errno, tabela de tradução de sinais, várias funções para atender às necessidades da syscall (correção de pilha, coredumping, etc.). Toda ABI que o kernel do FreeBSD deseja suportar deve definir essa estrutura, como é usado posteriormente no código de processamento da syscall e em alguns outros lugares. As entradas do sistema são tratadas pelos manipuladores de traps, onde podemos acessar o espaço do kernel e o espaço do usuário de uma só vez.
Syscalls 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. Syscalls no FreeBSD são emitidos executando a interrupção <literal> 0x80 </literal> com o registrador <varname>%eax</varname> definido para um número de syscall desejado com argumentos passados na pilha.
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. Quando um processo emite uma interrupção <literal>0x80</literal>, a syscall manipuladora de trap <literal>int0x80</literal> é proclamada (definida em <filename>sys/i386/i386/exception.s</filename>), que prepara argumentos (ou seja, copia-os para a pilha) para uma chamada para uma função C <citerefentry><refentrytitle>syscall</refentrytitle><manvolnum>2</manvolnum></citerefentry> (definida em <filename>sys/i386/i386/trap.c</filename>), que processa o trapframe passado. O processamento consiste em preparar a syscall (dependendo da entrada <literal>sysvec</literal>), determinando se a syscall é de 32 ou 64 bits (muda o tamanho dos parâmetros), então os parâmetros são copiados, incluindo a syscall. Em seguida, a função syscall real é executada com o processamento do código de retorno (casos especiais para erros <literal>ERESTART</literal> e <literal>EJUSTRETURN</literal>). Finalmente, um <literal>userret()</literal> é agendado, trocando o processo de volta ao ritmo do usuário. Os parâmetros para a syscall manipuladora atual são passados na forma de argumentos <literal>struct thread *td </literal>, <literal>struct syscall args*</literal> onde o segundo parâmetro é um ponteiro para o copiado na estrutura de parâmetros.
Traps Armadilhas (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>. O manuseio de traps no FreeBSD é similar ao manuseio de syscalls. Sempre que ocorre uma trap, um manipulador de assembler é chamado. É escolhido entre alltraps, alltraps com regs push ou calltrap, dependendo do tipo de trap. Este manipulador prepara argumentos para uma chamada para uma função C <literal>trap()</literal> (definida em <filename>sys/i386/i386/trap.c</filename>), que então processa a trap ocorrida. Após o processamento, ele pode enviar um sinal para o processo e/ou sair para o espaço do usuário usando <literal>userret()</literal>.
Exits Saídas
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. As saídas do kernel para o userspace acontecem usando a rotina assembler <literal>doreti</literal>, independentemente de o kernel ter sido acessado por meio de uma trap ou via syscall. Isso restaura o status do programa da pilha e retorna ao espaço do usuário.
<trademark class="registered">UNIX</trademark> primitives primitivas <trademark class="registered">UNIX</trademark>
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. O sistema operacional FreeBSD adere ao esquema tradicional <trademark class="registered">UNIX</trademark>, onde cada processo possui um número de identificação único, o chamado <firstterm>PID</firstterm> (ID do processo). Números PID são alocados de forma linear ou aleatória variando de <literal>0</literal> para <literal>PID_MAX</literal>. A alocação de números PID é feita usando pesquisa linear de espaço PID. Cada thread em um processo recebe o mesmo número PID como resultado da chamada <citerefentry><refentrytitle>getpid</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
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. Atualmente existem duas maneiras de implementar o threading no FreeBSD. A primeira maneira é o threading M:N seguido pelo modelo de threading 1:1. A biblioteca padrão usada é o threading M:N (<literal>libpthread</literal>) e você pode alternar no tempo de execução para threading 1:1 (<literal>libthr</literal>). O plano é mudar para a biblioteca 1:1 por padrão em breve. Embora essas duas bibliotecas usem as mesmas primitivas do kernel, elas são acessadas por API(s) diferentes. A biblioteca M:N usa a família <literal>kse_*</literal> das syscalls enquanto a biblioteca 1:1 usa a família <literal>thr_*</literal> das syscalls. Por causa disso, não existe um conceito geral de ID de threading compartilhado entre o kernel e o espaço do usuário. Obviamente, as duas bibliotecas de threads implementam a API de ID de threading pthread. Todo threading do kernel (como descrito por <literal>struct thread</literal>) possui identificadores td tid, mas isso não é diretamente acessível a partir do espaço do usuário e serve apenas as necessidades do kernel. Ele também é usado para a biblioteca de threading 1:1 como o ID de threading do pthread, mas a manipulação desta é interna à biblioteca e não pode ser confiável.
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). Como dito anteriormente, existem duas implementações de threads no FreeBSD. A biblioteca M:N divide o trabalho entre o espaço do kernel e o espaço do usuário. Thread é uma entidade que é agendada no kernel, mas pode representar vários números de threads do userspace. Threads M do userspace são mapeadas para threads N do kernel, economizando recursos e mantendo a capacidade de explorar o paralelismo de multiprocessadores. Mais informações sobre a implementação podem ser obtidas na página do manual ou [1]. A biblioteca 1:1 mapeia diretamente um segmento userland para uma thread do kernel, simplificando muito o esquema. Nenhum desses designs implementa um mecanismo justo (tal mecanismo foi implementado, mas foi removido recentemente porque causou séria lentidão e tornou o código mais difícil de lidar).
What is <trademark class="registered">Linux</trademark> O que é <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> é um kernel do tipo <trademark class="registered">UNIX</trademark> originalmente desenvolvido por Linus Torvalds, e agora está sendo contribuído por uma grande quantidade de programadores em todo o mundo. De seu simples começo até hoje, com amplo suporte de empresas como IBM ou Google, o <trademark class="registered">Linux</trademark> está sendo associado ao seu rápido ritmo de desenvolvimento, suporte completo a hardware e seu benevolente modelo despota de organização.
<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. O desenvolvimento do <trademark class="registered">Linux</trademark> começou em 1991 como um projeto amador na Universidade de Helsinque na Finlândia. Desde então, ele obteve todos os recursos de um sistema operacional semelhante ao UNIX: multiprocessamento, suporte multiusuário, memória virtual, rede, basicamente tudo está lá. Também há recursos altamente avançados, como virtualização, 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. A partir de 2006, o Linux parece ser o sistema operacional de código aberto mais utilizado com o apoio de fornecedores independentes de software como Oracle, RealNetworks, Adobe, etc. A maioria dos softwares comerciais distribuídos para <trademark class="registered">Linux</trademark> só pode ser obtido de forma binária, portanto a recompilação para outros sistemas operacionais é impossível.
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. A maior parte do desenvolvimento do <trademark class="registered">Linux</trademark> acontece em um sistema de controle de versão <application>Git</application>. O <application>Git</application> é um sistema distribuído, de modo que não existe uma fonte central do código <trademark class="registered">Linux</trademark>, mas algumas ramificações são consideradas proeminentes e oficiais. O esquema de número de versão implementado pelo <trademark class="registered">Linux</trademark> consiste em quatro números A.B.C.D. Atualmente, o desenvolvimento acontece em 2.6.C.D, onde C representa a versão principal, onde novos recursos são adicionados ou alterados, enquanto D é uma versão secundária somente para correções de bugs.
More information can be obtained from [3]. Mais informações podem ser obtidas em [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]. O <trademark class="registered">Linux</trademark> segue o esquema tradicional do <trademark class="registered">UNIX</trademark> de dividir a execução de um processo em duas metades: o kernel e o espaço do usuário. O kernel pode ser inserido de duas maneiras: via trap ou via syscall. O retorno é tratado apenas de uma maneira. A descrição mais detalhada aplica-se ao <trademark class="registered">Linux</trademark> 2.6 na arquitetura <trademark>i386</trademark>. Esta informação foi retirada de [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: Syscalls em <trademark class="registered">Linux</trademark> são executados (no espaço de usuário) usando macros <literal>syscallX</literal> onde X substitui um número que representa o número de parâmetros da syscall dada. Essa macro traduz um código que carrega o registro <varname>% eax </varname> com um número da syscall e executa a interrupção <literal>0x80</literal>. Depois disso, um retorn da syscall é chamado, o que traduz valores de retorno negativos para valores <literal>errno</literal> positivos e define <literal>res</literal> para <literal>-1</literal> em caso de erro. Sempre que a interrupção <literal>0x80</literal> é chamada, o processo entra no kernel no manipulador de trap das syscalls. Essa rotina salva todos os registros na pilha e chama a entrada syscall selecionada. Note que a convenção de chamadas <trademark class="registered">Linux</trademark> espera que os parâmetros para o syscall sejam passados pelos registradores como mostrado aqui:
parameter -&gt; <varname>%ebx</varname> parameter -&gt; <varname>%ebx</varname>
parameter -&gt; <varname>%ecx</varname> parameter -&gt; <varname>%ecx</varname>
parameter -&gt; <varname>%edx</varname> parameter -&gt; <varname>%edx</varname>
parameter -&gt; <varname>%esi</varname> parameter -&gt; <varname>%esi</varname>
parameter -&gt; <varname>%edi</varname> parameter -&gt; <varname>%edi</varname>
parameter -&gt; <varname>%ebp</varname> parameter -&gt; <varname>%ebp</varname>

Loading…

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 ofDue 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.
a month ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect4/para
Source string location
article.translate.xml:413
String age
a month ago
Source string age
a month ago
Translation file
articles/pt_BR/linux-emulation.po, string 68