Page MenuHomeFreeBSD
Differential D17032 Diff 47743 head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml

Changeset View

Standalone View

View Options

head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml

PropertyOld ValueNew Value
svn:keywordsnullFreeBSD=%H
\ No newline at end of property
svn:mime-typenulltext/xml; charset=UTF-8
\ No newline at end of property
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
<!-- $FreeBSD$ -->
<!-- The FreeBSD Documentation Project -->
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:lang="pt_BR">
<info>
<title>Emulação de <trademark class="registered"> Linux </trademark> no FreeBSD</title>
<author><personname> <firstname>Roman</firstname> <surname>Divacky</surname> </personname> <affiliation> <address>
<email>rdivacky@FreeBSD.org</email>
</address> </affiliation></author>
<legalnotice xml:id="trademarks" role="trademarks">
<para>Adobe, Acrobat, Acrobat Reader, Flash and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.</para>
<para>IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business Machines Corporation in the United States, other countries, or both.</para>
<para>FreeBSD is a registered trademark of the FreeBSD Foundation.</para>
<para>Linux is a registered trademark of Linus Torvalds.</para>
<para>NetBSD is a registered trademark of the NetBSD Foundation.</para>
<para>RealNetworks, RealPlayer, and RealAudio are the registered trademarks of RealNetworks, Inc.</para>
<para>Oracle is a registered trademark of Oracle Corporation.</para>
<para>Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.</para>
<para>Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol.</para>
</legalnotice>
<pubdate>$FreeBSD$</pubdate>
<releaseinfo>$FreeBSD$</releaseinfo>
<abstract>
<para>Essa tese master lida com a atualização da camada de emulação do <trademark class="registered">Linux</trademark> (o chamado <firstterm>Linuxulator</firstterm>). A tarefa foi atualizar a camada para casar com a funcionalidade do <trademark class="registered">Linux</trademark> 2.6. Como uma referencia a implementação, o kernel <trademark class="registered">Linux</trademark> 2.6.16 foi escolhido. O conceito é perdidamente baseado na implementação do NetBSD. Maior parte do trabalho foi feito no verão de 2006 como parte de um programa de estudante do Google Summer of Code. O foco foi trazer o suporte do <firstterm>NPTL</firstterm> (nova biblioteca de threads <trademark class="registered">POSIX</trademark>) pra dentro da camada de emulação, incluindo <firstterm>TLS</firstterm> (thread local storage), <firstterm>futexes</firstterm> (mutexes rapidos na camada de usuario), <firstterm>PID mangling</firstterm>, e algumas outras coisas menores. Muitos pequenos problemas foram identificados e corrigidos. Meu trabalho foi integrado dentro do repositório de principal do FreeBSD e vai ser ligado ao 7.0R release. Nós, o time de desenvolvimento de emulação estamos trabalhando na emulação do <trademark class="registered">Linux</trademark> 2.6 a camada de emulação padr
ão do FreeBSD.</para>
</abstract>
</info>
<sect1 xml:id="intro">
<title>Introdução</title>
<para>Nos últimos anos, os sistemas operacionais baseados em código aberto <trademark class="registered">UNIX</trademark> começaram a ser amplamente implantados em máquinas servidores e clientes. Entre esses sistemas operacionais eu gostaria de destacar dois: FreeBSD, por sua herança BSD, base de código comprovada pelo tempo e muitos recursos interessantes e <trademark class="registered">Linux</trademark> por sua ampla base de usuários, entusiasta comunidade aberta de desenvolvedores e apoio de grandes empresas. O FreeBSD tende a ser usado em máquinas de classe servidor, tarefas de rede pesadas com menos uso em máquinas de classe desktop para usuários comuns. Embora o <trademark class="registered">Linux</trademark> tenha o mesmo uso em servidores, mas é muito mais usado por usuários domésticos. Isto leva a uma situação onde existem muitos programas binários disponíveis apenas para <trademark class="registered">Linux</trademark> que não suportam o FreeBSD.</para>
<para>Naturalmente, surge a necessidade da habilidade de executar binários <trademark class="registered">Linux</trademark> em um sistema FreeBSD e é com isso que esta tese trata: a emulação do kernel do <trademark class="registered">Linux</trademark> no sistema operacional FreeBSD.</para>
<para>Durante o verão de 2006, a Google Inc. patrocinou um projeto que se concentrava em estender a camada de emulação do <trademark class="registered">Linux</trademark> (o chamado Linuxulator) no FreeBSD para incluir necessidades do <trademark class="registered">Linux</trademark> 2.6. Esta tese é escrita como parte deste projeto.</para>
</sect1>
<sect1 xml:id="inside">
<title>Um olhar para dentro ...</title>
<para>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.</para>
<sect2 xml:id="what-is-unix">
<title>O que é o <trademark class="registered"> UNIX </trademark>?</title>
<para><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>.</para>
</sect2>
<sect2 xml:id="tech-details">
<title>Detalhes técnicos</title>
<para>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.</para>
<sect3 xml:id="kern-proc-comm">
<title>Comunicação entre o kernel e o processo de espaço do usuário</title>
<para>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.</para>
<para>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).</para>
</sect3>
<sect3 xml:id="proc-proc-comm">
<title>Comunicação entre processos</title>
<para>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.</para>
</sect3>
<sect3 xml:id="proc-mgmt">
<title>Gerenciamento de processos</title>
<para>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).</para>
</sect3>
<sect3 xml:id="thread-mgmt">
<title>Gerenciamento de threads</title>
<para>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:</para>
<para>1:1 threading</para>
<itemizedlist>
<listitem>
<para>- threads pesadas</para>
</listitem>
<listitem>
<para>- o agendamento não pode ser alterado pelo usuário (ligeiramente mitigado pela API <trademark class="registered"> POSIX </trademark>)</para>
</listitem>
<listitem>
<para>+ não necessita de envolvimento do syscall</para>
</listitem>
<listitem>
<para>+ pode utilizar várias CPUs</para>
</listitem>
</itemizedlist>
<para>1: N threading</para>
<itemizedlist>
<listitem>
<para>+ threads leves</para>
</listitem>
<listitem>
<para>+ agendamento pode ser facilmente alterado pelo usuário</para>
</listitem>
<listitem>
<para>- syscalls devem ser acondicionadas</para>
</listitem>
<listitem>
<para>- não pode utilizar mais de uma CPU</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 xml:id="what-is-freebsd">
<title>O que é o FreeBSD?</title>
<para>O projeto FreeBSD é um dos mais antigos sistemas operacionais de código aberto atualmente disponíveis para uso diário. É um descendente direto do verdadeiro <trademark class="registered">UNIX</trademark>, portanto, pode-se afirmar que ele é um verdadeiro <trademark class="registered">UNIX</trademark> embora os problemas de licenciamento não permitam isso. O início do projeto remonta ao início dos anos 90, quando uma equipe de usuários BSD corrigiu o sistema operacional 386BSD. Baseado neste patchkit surgiu um novo sistema operacional, chamado FreeBSD por sua licença liberal. Outro grupo criou o sistema operacional NetBSD com diferentes objetivos em mente. Vamos nos concentrar no FreeBSD.</para>
<para>O FreeBSD é um sistema operacional baseado no <trademark class="registered">UNIX</trademark> com todos os recursos do <trademark class="registered">UNIX</trademark>. Multitarefa preemptiva, necessidades de multiusuário, rede TCP/IP, proteção de memória, suporte a multiprocessamento simétrico, memória virtual com VM mesclada e cache de buffer, todos eles estão lá. Um dos recursos interessantes e extremamente úteis é a capacidade de emular outros sistemas operacionais <trademark class="registered">UNIX</trademark>-like. A partir de dezembro de 2006 e do desenvolvimento do 7-CURRENT, as seguintes funcionalidades de emulação são suportadas:</para>
<itemizedlist>
<listitem>
<para>Emulação FreeBSD/i386 no FreeBSD/amd64</para>
</listitem>
<listitem>
<para>Emulação de FreeBSD/i386 no FreeBSD/ia64</para>
</listitem>
<listitem>
<para>Emulação-<trademark class="registered">Linux</trademark> do sistema operacional <trademark class="registered"> Linux </trademark> no FreeBSD</para>
</listitem>
<listitem>
<para>Emulação de NDIS da interface de drivers de rede do Windows</para>
</listitem>
<listitem>
<para>Emulação de NetBSD do sistema operacional NetBSD</para>
</listitem>
<listitem>
<para>Suporte PECoff para executáveis PECoff !!do FreeBSD</para>
</listitem>
<listitem>
<para>Emulação SVR4 do <trademark class="registered">UNIX</trademark> System V revisão 4 </para>
</listitem>
</itemizedlist>
<para>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.</para>
<sect3 xml:id="freebsd-tech-details">
<title>Detalhes técnicos</title>
<para>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.</para>
<sect4 xml:id="freebsd-sys-entries">
<title>Entradas do sistema</title>
<para>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.</para>
</sect4>
<sect4 xml:id="freebsd-syscalls">
<title>Syscalls</title>
<para>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.</para>
<para>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.</para>
</sect4>
<sect4 xml:id="freebsd-traps">
<title>Armadilhas (Traps)</title>
<para>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>.</para>
</sect4>
<sect4 xml:id="freebsd-exits">
<title>Saídas</title>
<para>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.</para>
</sect4>
<sect4 xml:id="freebsd-unix-primitives">
<title>primitivas <trademark class="registered">UNIX</trademark></title>
<para>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>.</para>
<para>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.</para>
<para>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).</para>
</sect4>
</sect3>
</sect2>
<sect2 xml:id="what-is-linux">
<title>O que é <trademark class="registered">Linux</trademark></title>
<para><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.</para>
<para>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.</para>
<para>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.</para>
<para>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.</para>
<para>Mais informações podem ser obtidas em [3].</para>
<sect3 xml:id="linux-tech-details">
<title>Detalhes técnicos</title>
<para>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].</para>
<sect4 xml:id="linux-syscalls">
<title>Syscalls</title>
<para>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:</para>
<orderedlist>
<listitem>
<para>parameter -&gt; <varname>%ebx</varname></para>
</listitem>
<listitem>
<para>parameter -&gt; <varname>%ecx</varname></para>
</listitem>
<listitem>
<para>parameter -&gt; <varname>%edx</varname></para>
</listitem>
<listitem>
<para>parameter -&gt; <varname>%esi</varname></para>
</listitem>
<listitem>
<para>parameter -&gt; <varname>%edi</varname></para>
</listitem>
<listitem>
<para>parameter -&gt; <varname>%ebp</varname></para>
</listitem>
</orderedlist>
<para>Existem algumas exceções, onde <trademark class="registered">Linux</trademark> usa diferentes convenções de chamada (mais notavelmente a syscall <literal>clone</literal>).</para>
</sect4>
<sect4 xml:id="linux-traps">
<title>Armadilhas (Traps)</title>
<para>Os manipuladores de traps são apresentados em <filename>arch/i386/kernel/traps.c</filename> e a maioria desses manipuladores vive em <filename>arch/i386/kernel/entry.S</filename>, onde a manipulação das traps acontecem.</para>
</sect4>
<sect4 xml:id="linux-exits">
<title>Saídas</title>
<para>O retorno da syscall é gerenciado pela syscall <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, que verifica se o processo não está concluído e verifica se usamos seletores fornecidos pelo usuário . Se isso acontecer, a correção da pilha é aplicada e, finalmente, os registros são restaurados da pilha e o processo retorna ao espaço do usuário.</para>
</sect4>
<sect4 xml:id="linux-unix-primitives">
<title>primitivas <trademark class="registered">UNIX</trademark></title>
<para>Na versão 2.6, o sistema operacional <trademark class="registered">Linux</trademark> redefiniu algumas das primitivas tradicionais do <trademark class="registered">UNIX</trademark>, especialmente PID, TID e thread. O PID é definido para não ser exclusivo para cada processo, portanto, para alguns processos (threading) <citerefentry><refentrytitle>getppid</refentrytitle><manvolnum>2</manvolnum></citerefentry> retorna o mesmo valor. A identificação exclusiva do processo é fornecida pelo TID. Isso ocorre porque o <firstterm>NPTL</firstterm> (Nova Biblioteca de threading <trademark class="registered">POSIX</trademark>) define threading para serem processos normais (assim chamado threading 1:1). Gerar um novo processo no <trademark class="registered">Linux</trademark> 2.6 acontece usando a syscall <literal>clone</literal> (as variantes do fork são reimplementadas usando-o). Esta syscall clone define um conjunto de sinalizadores que afetam o comportamento do processo de clonagem em relação à implementação do threading. A semântica é um pouco confusa, pois não existe uma única bandeira dizendo a syscall para criar uma thread.</para>
<para>Flags de clone implementados são:</para>
<itemizedlist>
<listitem>
<para><literal>CLONE_VM</literal> - os processos compartilham seu espaço de memória</para>
</listitem>
<listitem>
<para><literal>CLONE_FS</literal> - compartilha umask, cwd e namespace</para>
</listitem>
<listitem>
<para><literal>CLONE_FILES</literal> - compartilham arquivos abertos</para>
</listitem>
<listitem>
<para><literal>CLONE_SIGHAND</literal> - compartilha manipuladores de sinais e bloqueia sinais</para>
</listitem>
<listitem>
<para><literal>CLONE_PARENT</literal> - compartilha processo pai</para>
</listitem>
<listitem>
<para><literal>CLONE_THREAD</literal> - ser a thread (mais explicações abaixo)</para>
</listitem>
<listitem>
<para><literal>CLONE_NEWNS</literal> - novo namespace</para>
</listitem>
<listitem>
<para><literal>CLONE_SYSVSEM</literal> - compartilha SysV sob estruturas</para>
</listitem>
<listitem>
<para><literal>CLONE_SETTLS</literal> - configura o TLS no endereço fornecido</para>
</listitem>
<listitem>
<para><literal>CLONE_PARENT_SETTID</literal> - define o TID no processo pai</para>
</listitem>
<listitem>
<para><literal>CLONE_CHILD_CLEARTID</literal> - limpe o TID no processo filho</para>
</listitem>
<listitem>
<para><literal>CLONE_CHILD_SETTID</literal> - define o TID no processo filho</para>
</listitem>
</itemizedlist>
<para><literal>CLONE_PARENT</literal> define o processo real para o processo pai do requisitante. Isso é útil para threads porque, se a thread A criar a thread B, queremos que a thread B parenteada para o processo pai de todo o grupo de threads. <literal>CLONE_THREAD</literal> faz exatamente a mesma coisa que <literal>CLONE_PARENT</literal>, <literal>CLONE_VM</literal> e <literal>CLONE_SIGHAND</literal>, reescreve o PID para ser o mesmo que PID do requisitante, define o sinal de saída como none e entra no grupo de threads. <literal>CLONE_SETTLS</literal> configura entradas GDT para tratamento de TLS. O conjunto de flags <literal>CLONE_*_*TID</literal> define/limpa o endereço fornecido pelo usuário para TID ou 0.</para>
<para>Como você pode ver, o <literal>CLONE_THREAD</literal> faz a maior parte do trabalho e não parece se encaixar muito bem no esquema. A intenção original não é clara (mesmo para autores, de acordo com comentários no código), mas acho que originalmente havia uma flag de thread, que foi então dividida entre muitas outras flags, mas essa separação nunca foi totalmente concluída. Também não está claro para que serve esta partição, uma vez que a glibc não usa isso, portanto, apenas o uso do clone escrito à mão permite que um programador acesse esses recursos.</para>
<para>Para programas não segmentados, o PID e o TID são os mesmos. Para programas em threadings, os primeiros PID e TID da thread são os mesmos e todos os threading criados compartilham o mesmo PID e são atribuídos a um TID exclusivo (porque <literal>CLONE_THREAD</literal> é passado), o processo pai também é compartilhado para todos os processos que formam esse threading do programa.</para>
<para>O código que implementa <citerefentry><refentrytitle>pthread_create</refentrytitle><manvolnum>3</manvolnum></citerefentry> no NPTL define as flags de clone como este:</para>
<programlisting>int clone_flags = (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGNAL
| CLONE_SETTLS | CLONE_PARENT_SETTID
| CLONE_CHILD_CLEARTID | CLONE_SYSVSEM
#if __ASSUME_NO_CLONE_DETACHED == 0
| CLONE_DETACHED
#endif
| 0);</programlisting>
<para>O <literal>CLONE_SIGNAL</literal> é definido como</para>
<programlisting>#define CLONE_SIGNAL (CLONE_SIGHAND | CLONE_THREAD)</programlisting>
<para>o último 0 significa que nenhum sinal é enviado quando qualquer uma das threads finaliza.</para>
</sect4>
</sect3>
</sect2>
<sect2 xml:id="what-is-emu">
<title>O que é emulação</title>
<para>De acordo com uma definição de dicionário, emulação é a capacidade de um programa ou dispositivo de imitar um outro programa ou dispositivo. Isto é conseguido fornecendo a mesma reação a um determinado estímulo que o objeto emulado. Na prática, o mundo do software vê três tipos de emulação - um programa usado para emular uma máquina (QEMU, vários emuladores de consoles de jogos etc.), emulação de software de uma instalação de hardware (emuladores OpenGL, emulação de unidades de ponto flutuante etc.) e emulação do sistema (no kernel do sistema operacional ou como um programa de espaço do usuário).</para>
<para>Emulação é geralmente usada em um lugar, onde o uso do componente original não é viável nem possível a todos. Por exemplo, alguém pode querer usar um programa desenvolvido para um sistema operacional diferente do que eles usam. Então a emulação vem a calhar. Por vezes, não há outra maneira senão usar emulação - por ex. Quando o dispositivo de hardware que você tenta usar não existe (ainda/mais), então não há outro caminho além da emulação. Isso acontece com frequência ao transferir um sistema operacional para uma nova plataforma (inexistente). Às vezes é mais barato emular.</para>
<para>Olhando do ponto de vista da implementação, existem duas abordagens principais para a implementação da emulação. Você pode emular a coisa toda - aceitando possíveis entradas do objeto original, mantendo o estado interno e emitindo a saída correta com base no estado e/ou na entrada. Este tipo de emulação não requer condições especiais e basicamente pode ser implementado em qualquer lugar para qualquer dispositivo/programa. A desvantagem é que a implementação de tal emulação é bastante difícil, demorada e propensa a erros. Em alguns casos, podemos usar uma abordagem mais simples. Imagine que você deseja emular uma impressora que imprime da esquerda para a direita em uma impressora que imprime da direita para a esquerda. É óbvio que não há necessidade de uma camada de emulação complexa, mas a simples reversão do texto impresso é suficiente. Às vezes, o ambiente de emulação é muito semelhante ao emulado, portanto, apenas uma camada fina de alguma tradução é necessária para fornecer uma emulação totalmente funcional! Como você pode ver, isso é muito menos exigente de implementar, portanto, menos demorado e propenso a erros do que a abordagem anterior. Mas a condição necessária é que os dois ambientes sejam semelhantes o suficiente. A terceira abordagem combina os dois anteriores. Na maioria das vezes, os objetos não fornecem os mesmos recursos, portanto, em um caso de emulação, o mais poderoso é o menos poderoso que temos para emular os recursos ausentes com a emulação completa descrita acima.</para>
<para>Esta tese de mestrado lida com a emulação de <trademark class="registered">UNIX</trademark> em <trademark class="registered">UNIX</trademark>, que é exatamente o caso, onde apenas uma camada fina de tradução é suficiente para fornecer emulação completa. A API do <trademark class="registered">UNIX</trademark> consiste em um conjunto de syscalls, que geralmente são autônomas e não afetam algum estado global do kernel.</para>
<para>Existem algumas syscalls que afetam o estado interno, mas isso pode ser resolvido fornecendo algumas estruturas que mantêm o estado extra.</para>
<para>Nenhuma emulação é perfeita e as emulações tendem a não ter algumas partes, mas isso geralmente não causa nenhuma desvantagem séria. Imagine um emulador de console de jogos que emula tudo, menos a saída de música. Não há dúvida de que os jogos são jogáveis !!e pode-se usar o emulador. Pode não ser tão confortável quanto o console original, mas é um compromisso aceitável entre preço e conforto.</para>
<para>O mesmo acontece com a API do <trademark class="registered">UNIX</trademark>. A maioria dos programas pode viver com um conjunto muito limitado de syscalls funcionando. Essas syscalls tendem a ser as mais antigas (<citerefentry><refentrytitle>read</refentrytitle><manvolnum>2</manvolnum></citerefentry>/<citerefentry><refentrytitle>write</refentrytitle><manvolnum>2</manvolnum></citerefentry>,<citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>family,<citerefentry> <refentrytitle>signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>handling, <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum> </citerefentry> API), portanto, é fácil emular porque sua semântica é compartilhada entre todos os <trademark class="registered">UNIX</trademark>, que existem hoje.</para>
</sect2>
</sect1>
<sect1 xml:id="freebsd-emulation">
<title>Emulação</title>
<sect2>
<title>Como funciona a emulação no FreeBSD</title>
<para>Como dito anteriormente, o FreeBSD suporta a execução de binários a partir de vários outros <trademark class="registered">UNIX</trademark>. Isso funciona porque o FreeBSD tem uma abstração chamada loader de classes de execução. Isso se encaixa na syscall <citerefentry><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>, então quando <citerefentry><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> está prestes a executar um binário que examina seu tipo.</para>
<para>Existem basicamente dois tipos de binários no FreeBSD. Scripts de texto semelhantes a shell que são identificados por <literal>#!</literal> como seus dois primeiros caracteres e binários normais (normalmente <firstterm>ELF</firstterm>), que são uma representação de um objeto executável compilado. A grande maioria (pode-se dizer todos eles) de binários no FreeBSD é do tipo ELF. Os arquivos ELF contêm um cabeçalho, que especifica a ABI do OS para este arquivo ELF. Ao ler essas informações, o sistema operacional pode determinar com precisão o tipo de binário do arquivo fornecido.</para>
<para>Toda ABI de OS deve ser registrada no kernel do FreeBSD. Isso também se aplica ao sistema operacional nativo do FreeBSD. Então, quando <citerefentry><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> executa um binário, ele itera através da lista de APIs registradas e quando ele encontra a correta, ele começa a usar as informações contidas na descrição da ABI do OS (sua tabela syscall, tabela de tradução <literal>errno</literal>, etc.). Assim, toda vez que o processo chama uma syscall, ele usa seu próprio conjunto de syscalls em vez de uma global. Isso efetivamente fornece uma maneira muito elegante e fácil de suportar a execução de vários formatos binários.</para>
<para>A natureza da emulação de diferentes sistemas operacionais (e também alguns outros subsistemas) levou os desenvolvedores a invitar um mecanismo de evento manipulador. Existem vários locais no kernel, onde uma lista de manipuladores de eventos é chamada. Cada subsistema pode registrar um manipulador de eventos e eles são chamados de acordo com sua necessidade. Por exemplo, quando um processo é encerrado, há um manipulador chamado que possivelmente limpa o que o subsistema que ele precisa de limpeza.</para>
<para>Essas facilidades simples fornecem basicamente tudo o que é necessário para a infra-estrutura de emulação e, de fato, essas são basicamente as únicas coisas necessárias para implementar a camada de emulação do <trademark class="registered">Linux</trademark>.</para>
</sect2>
<sect2 xml:id="freebsd-common-primitives">
<title>Primitivas comuns no kernel do FreeBSD</title>
<para>Camadas de emulação precisam de algum suporte do sistema operacional. Eu vou descrever algumas das primitivas suportadas no sistema operacional FreeBSD.</para>
<sect3 xml:id="freebsd-locking-primitives">
<title>Primitivas de Bloqueio</title>
<para>Contribuído por: Attilio Rao <email>attilio@FreeBSD.org</email></para>
<para>O conjunto de primitivas de sincronização do FreeBSD é baseado na idéia de fornecer um grande número de diferentes primitivas de uma maneira que a melhor possa ser usada para cada situação específica e apropriada.</para>
<para>Para um ponto de vista de alto nível, você pode considerar três tipos de primitivas de sincronização no kernel do FreeBSD:</para>
<itemizedlist>
<listitem>
<para>operações atômicas e barreiras de memória</para>
</listitem>
<listitem>
<para>locks</para>
</listitem>
<listitem>
<para>barreiras de agendamento</para>
</listitem>
</itemizedlist>
<para>Abaixo, há descrições para as 3 famílias. Para cada bloqueio, você deve verificar a página de manual vinculada (onde for possível) para obter explicações mais detalhadas.</para>
<sect4 xml:id="freebsd-atomic-op">
<title>Operações atômicas e barreiras de memória</title>
<para>Operações atômicas são implementadas através de um conjunto de funções que executam aritmética simples em operandos de memória de maneira atômica com relação a eventos externos (interrupções, preempção, etc.). Operações atômicas podem garantir atomicidade apenas em pequenos tipos de dados (na ordem de magnitude do tipo de dados C da arquitetura <literal>.long.</literal>), portanto raramente devem ser usados !!diretamente no código de nível final, se não apenas para operações muito simples (como configuração de flags em um bitmap, por exemplo). De fato, é bastante simples e comum escrever uma semântica errada baseada apenas em operações atômicas (geralmente referidas como lock-less). O kernel do FreeBSD oferece uma maneira de realizar operações atômicas em conjunto com uma barreira de memória. As barreiras de memória garantirão que uma operação atômica ocorrerá seguindo alguma ordem especificas em relação a outros acessos à memória. Por exemplo, se precisarmos que uma operação atômica aconteça logo depois que todas as outras gravações pendentes (em termos de instruções reordenando atividades de buffers) forem concluídas, precisamos usar explicitamente uma barreira de memória em conjunto com essa operação atômica. Portanto, é simples entender por que as barreiras de memória desempenham um papel fundamental na construção de bloqueios de alto nível (assim como referências, exclusões mútuas, etc.). Para uma explicação detalhada sobre operações atômicas, consulte <citerefentry><refentrytitle>atomic</refentrytitle><manvolnum>9</manvolnum></citerefentry>. É muito, no entanto, notar que as operações atômicas (e as barreiras de memória também) devem, idealmente, ser usadas apenas para construir bloqueios front-ending (como mutexes).</para>
</sect4>
<sect4 xml:id="freebsd-refcounts">
<title>Refcounts</title>
<para>Refcounts são interfaces para manipular contadores de referência. Eles são implementados por meio de operações atômicas e destinam-se a ser usados !!apenas para casos em que o contador de referência é a única coisa a ser protegida, portanto, até mesmo algo como um spin-mutex é obsoleto. Usar a interface de recontagem para estruturas, onde um mutex já é usado, geralmente está errado, pois provavelmente devemos fechar o contador de referência em alguns caminhos já protegidos. Uma manpage discutindo refcount não existe atualmente, apenas verifique <filename>sys/refcount.h</filename> para uma visão geral da API existente.</para>
</sect4>
<sect4 xml:id="freebsd-locks">
<title>Locks</title>
<para>O kernel do FreeBSD tem enormes classes de bloqueios. Cada bloqueio é definido por algumas propriedades peculiares, mas provavelmente o mais importante é o evento vinculado a detentores de contestação (ou, em outros termos, o comportamento de threading incapazes de adquirir o bloqueio). O esquema de bloqueio do FreeBSD apresenta três comportamentos diferentes para contendores:</para>
<orderedlist>
<listitem>
<para>spinning</para>
</listitem>
<listitem>
<para>blocking</para>
</listitem>
<listitem>
<para>sleeping</para>
</listitem>
</orderedlist>
<note>
<para>números não são casuais</para>
</note>
</sect4>
<sect4 xml:id="freebsd-spinlocks">
<title>Spinning locks</title>
<para>Spin locks permitem que os acumuladores rotacionarem até que eles não consigam adquirir um lock. Uma questão importante é quando um segmento contesta em um spin lock se não for desmarcado. Uma vez que o kernel do FreeBSD é preventivo, isto expõe o spin lock ao risco de deadlocks que podem ser resolvidos apenas desabilitando as interrupções enquanto elas são adquiridas. Por essa e outras razões (como falta de suporte à propagação de prioridade, falta de esquemas de balanceamento de carga entre CPUs, etc.), os spin locks têm a finalidade de proteger endereçamentos muito pequenos de código ou, idealmente, não serem usados !!se não solicitados explicitamente ( explicado posteriormente).</para>
</sect4>
<sect4 xml:id="freebsd-blocking">
<title>Bloqueio</title>
<para>Os locks em blocos permitem que as tarefas dos acumuladores sejam removidas e bloqueados até que o proprietário do bloqueio não os libere e ative um ou mais contendores. Para evitar problemas de fome, os locks em bloco fazem a propagação de prioridade dos acumuladores para o proprietário. Os locks em bloco devem ser implementados por meio da interface turnstile e devem ser o tipo mais usado de bloqueios no kernel, se nenhuma condição específica for atendida.</para>
</sect4>
<sect4 xml:id="freebsd-sleeping">
<title>Sleeping</title>
<para>Sleep locks permitem que as tarefas dos waiters sejam removidas e eles adormecem até que o suporte do lock não os deixe cair e desperte um ou mais waiters. Como os sleep locks se destinam a proteger grandes endereçamentos de código e a atender a eventos assíncronos, eles não fazem nenhuma forma de propagação de prioridade. Eles devem ser implementados por meio da interface <citerefentry><refentrytitle>sleepqueue</refentrytitle><manvolnum>9</manvolnum></citerefentry>.</para>
<para>A ordem usada para adquirir locks é muito importante, não apenas pela possibilidade de deadlock devido a reversões de ordem de bloqueio, mas também porque a aquisição de lock deve seguir regras específicas vinculadas a naturezas de bloqueios. Se você der uma olhada na tabela acima, a regra prática é que, se um segmento contiver um lock de nível n (onde o nível é o número listado próximo ao tipo de bloqueio), não é permitido adquirir um lock de níveis superiores , pois isso quebraria a semântica especificada para um caminho. Por exemplo, se uma thread contiver um lock em bloco (nível 2), ele poderá adquirir um spin lock (nível 1), mas não um sleep lock (nível 3), pois os locks em bloco são destinados a proteger caminhos menores que o sleep lock ( essas regras não são sobre operações atômicas ou agendamento de barreiras, no entanto).</para>
<para>Esta é uma lista de bloqueio com seus respectivos comportamentos:</para>
<itemizedlist>
<listitem>
<para>spin mutex - spinning - <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>sleep mutex - blocking - <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>pool mutex - blocking - <citerefentry><refentrytitle>mtx_pool</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>família sleep - sleeping - <citerefentry><refentrytitle>sleep</refentrytitle><manvolnum>9</manvolnum></citerefentry> pausa tsleep msleep msleep spin msleep rw msleep sx</para>
</listitem>
<listitem>
<para>condvar - sleeping - <citerefentry><refentrytitle>condvar</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>wlock - blocking - <citerefentry><refentrytitle>rwlock</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>sxlock - sleeping - <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>lockmgr - sleeping - <citerefentry><refentrytitle>lockmgr</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
<listitem>
<para>semáforos - sleeping - <citerefentry><refentrytitle>sema</refentrytitle><manvolnum>9</manvolnum></citerefentry></para>
</listitem>
</itemizedlist>
<para>Entre esses bloqueios, apenas mutexes, sxlocks, rwlocks e lockmgrs são destinados a tratar recursão, mas atualmente a recursão é suportada apenas por mutexes e lockmgrs.</para>
</sect4>
<sect4 xml:id="freebsd-scheduling">
<title>Barreiras de agendamento</title>
<para>As barreiras de agendamento devem ser usadas para orientar o agendamento de threads. Eles consistem principalmente de três diferentes stubs:</para>
<itemizedlist>
<listitem>
<para>seções críticas (e preempção)</para>
</listitem>
<listitem>
<para>sched_bind</para>
</listitem>
<listitem>
<para>sched_pin</para>
</listitem>
</itemizedlist>
<para>Geralmente, eles devem ser usados !!apenas em um contexto específico e, mesmo que possam substituir bloqueios, eles devem ser evitados porque eles não permitem o diagnóstico de problemas simples com ferramentas de depuração de bloqueio (como <citerefentry><refentrytitle>witness</refentrytitle><manvolnum>4</manvolnum></citerefentry>).</para>
</sect4>
<sect4 xml:id="freebsd-critical">
<title>Seções críticas</title>
<para>O kernel do FreeBSD foi feito basicamente para lidar com threads de interrupção. De fato, para evitar latência de interrupção alta, os segmentos de prioridade de compartilhamento de tempo podem ser precedidos por threads de interrupção (dessa forma, eles não precisam aguardar para serem agendados como as visualizações de caminho normais). Preempção, no entanto, introduz novos pontos de corrida que precisam ser manipulados também. Muitas vezes, para lidar com a preempção, a coisa mais simples a fazer é desativá-la completamente. Uma seção crítica define um pedaço de código (delimitado pelo par de funções <citerefentry><refentrytitle>critical_enter</refentrytitle><manvolnum>9</manvolnum> </citerefentry> e <citerefentry><refentrytitle>critical_exit</refentrytitle><manvolnum>9</manvolnum></citerefentry>, onde é garantido que a preempção não aconteça (até que o código protegido seja totalmente executado) Isso pode substituir um bloqueio efetivamente, mas deve ser usado com cuidado para não perder toda a vantagem essa preempção traz.</para>
</sect4>
<sect4 xml:id="freebsd-schedpin">
<title>sched_pin/sched_unpin</title>
<para>Outra maneira de lidar com a preempção é a interface <function>sched_pin()</function>. Se um trecho de código é fechado no par de funções <function>sched_pin()</function> e <function>sched_unpin()</function>, é garantido que a respectiva thread, mesmo que possa ser antecipada, sempre ser executada na mesma CPU. Fixar é muito eficaz no caso particular quando temos que acessar por dados do cpu e assumimos que outras threads não irão alterar esses dados. A última condição determinará uma seção crítica como uma condição muito forte para o nosso código.</para>
</sect4>
<sect4 xml:id="freebsd-schedbind">
<title>sched_bind/sched_unbind</title>
<para><function>sched_bind</function> é uma API usada para vincular uma thread a uma CPU em particular durante todo o tempo em que ele executa o código, até que uma chamada de função <function>sched_unbind</function> não a desvincule. Esse recurso tem um papel importante em situações em que você não pode confiar no estado atual das CPUs (por exemplo, em estágios iniciais de inicialização), já que você deseja evitar que sua thread migre em CPUs inativas. Como <function>sched_bind</function> e <function>sched_unbind</function> manipulam as estruturas internas do agendador, elas precisam estar entre a aquisição/liberação de <function>sched_lock</function> quando usadas.</para>
</sect4>
</sect3>
<sect3 xml:id="freebsd-proc">
<title>Estrutura Proc</title>
<para>Várias camadas de emulação exigem alguns dados adicionais por processo. Ele pode gerenciar estruturas separadas (uma lista, uma árvore etc.) contendo esses dados para cada processo, mas isso tende a ser lento e consumir memória. Para resolver este problema, a estrutura <literal>proc</literal> do FreeBSD contém <literal>p_emuldata</literal>, que é um ponteiro vazio para alguns dados específicos da camada de emulação. Esta entrada <literal>proc</literal> é protegida pelo mutex proc.</para>
<para>A estrutura <literal>proc</literal> do FreeBSD contém uma entrada <literal>p_sysent</literal> que identifica, qual ABI este processo está executando. Na verdade, é um ponteiro para o <literal>sysentvec</literal> descrito acima. Portanto, comparando esse ponteiro com o endereço em que a estrutura <literal>sysentvec</literal> da ABI especificada está armazenada, podemos efetivamente determinar se o processo pertence à nossa camada de emulação. O código normalmente se parece com:</para>
<programlisting>if (__predict_true(p-&gt;p_sysent != &amp;elf_<trademark class="registered">Linux</trademark>_sysvec))
return;</programlisting>
<para>Como você pode ver, usamos efetivamente o modificador <literal>__predict_true</literal> para recolher o caso mais comum (processo do FreeBSD) para uma operação de retorno simples, preservando assim o alto desempenho. Este código deve ser transformado em uma macro porque atualmente não é muito flexível, ou seja, não suportamos emulação <trademark class="registered">Linux</trademark>64 nem processa A.OUT <trademark class="registered">Linux</trademark> em i386.</para>
</sect3>
<sect3 xml:id="freebsd-vfs">
<title>VFS</title>
<para>O subsistema FreeBSD VFS é muito complexo, mas a camada de emulação <trademark class="registered">Linux</trademark> usa apenas um pequeno subconjunto através de uma API bem definida. Ele pode operar em vnodes ou manipuladores de arquivos. Vnode representa um vnode virtual, isto é, representação de um nó no VFS. Outra representação é um manipulador de arquivos, que representa um arquivo aberto da perspectiva de um processo. Um manipulador de arquivos pode representar um socket ou um arquivo comum. Um manipulador de arquivos contém um ponteiro para seu vnode. Mais de um manipulador de arquivos pode apontar para o mesmo vnode.</para>
<sect4 xml:id="freebsd-namei">
<title>namei</title>
<para>A rotina <citerefentry> <refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> é um ponto de entrada central para a pesquisa e o nome do caminho. Ele percorre o caminho ponto a ponto do ponto inicial até o ponto final usando a função de pesquisa, que é interna ao VFS. A syscall <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> pode lidar com links simbólicos, absolutos e relativos. Quando um caminho é procurado usando <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> ele é inserido no cache de nomes. Esse comportamento pode ser suprimido. Essa rotina é usada em todo o kernel e seu desempenho é muito crítico.</para>
</sect4>
<sect4 xml:id="freebsd-vn">
<title>vn_fullpath</title>
<para>A função <citerefentry><refentrytitle>vn_fullpath</refentrytitle><manvolnum>9</manvolnum></citerefentry> faz o melhor esforço para percorrer o cache de nomes do VFS e retorna um caminho para um determinado vnode (bloqueado). Esse processo não é confiável, mas funciona bem nos casos mais comuns. A falta de confiabilidade é porque ela depende do cache do VFS (ele não atravessa as estruturas intermediárias), não funciona com hardlinks, etc. Essa rotina é usada em vários locais no Linuxulator.</para>
</sect4>
<sect4 xml:id="freebsd-vnode">
<title>Operações de vnode</title>
<itemizedlist>
<listitem>
<para><function>fgetvp</function> - dado um encadeamento e um número de descritor de arquivo, ele retorna o vnode associado</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>vn_lock</refentrytitle><manvolnum>9</manvolnum></citerefentry> - bloqueia um vnode</para>
</listitem>
<listitem>
<para><function>vn_unlock</function> - desbloqueia um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>VOP_READDIR</refentrytitle><manvolnum>9</manvolnum></citerefentry> - lê um diretório referenciado por um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>VOP_GETATTR</refentrytitle><manvolnum>9</manvolnum></citerefentry> - obtém atributos de um arquivo ou diretório referenciado por um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>VOP_LOOKUP</refentrytitle><manvolnum>9</manvolnum></citerefentry> - procura um caminho para um determinado diretório</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>VOP_OPEN</refentrytitle><manvolnum>9</manvolnum></citerefentry> - abre um arquivo referenciado por um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>VOP_CLOSE</refentrytitle><manvolnum>9</manvolnum></citerefentry> - fecha um arquivo referenciado por um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>vput</refentrytitle><manvolnum>9</manvolnum></citerefentry> - decrementa a contagem de uso para um vnode e o desbloqueia</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>vrele</refentrytitle><manvolnum>9</manvolnum></citerefentry> - diminui a contagem de uso para um vnode</para>
</listitem>
<listitem>
<para><citerefentry><refentrytitle>vref</refentrytitle><manvolnum>9</manvolnum></citerefentry> - incrementa a contagem de uso para um vnode</para>
</listitem>
</itemizedlist>
</sect4>
<sect4 xml:id="freebsd-file-handler">
<title>Operações do manipulador de arquivos</title>
<itemizedlist>
<listitem>
<para><function>fget</function> - dado uma thread e um número de file descriptor, ele retorna o manipulador de arquivos associado e faz referência a ele</para>
</listitem>
<listitem>
<para><function>fdrop</function> - elimina uma referência a um manipulador de arquivos</para>
</listitem>
<listitem>
<para><function>fhold</function> - faz referência a um manipulador de arquivos</para>
</listitem>
</itemizedlist>
</sect4>
</sect3>
</sect2>
</sect1>
<sect1 xml:id="md">
<title>Parte da camada de emulação -MD do <trademark class="registered">Linux</trademark></title>
<para>Esta seção trata da implementação da camada de emulação do <trademark class="registered">Linux</trademark> no sistema operacional FreeBSD. Ele primeiro descreve a parte dependente da máquina falando sobre como e onde a interação entre o usuário e o kernel é implementada. Ele fala sobre syscalls, signals, ptrace, traps, correção de pilha. Esta parte discute o i386, mas ele é escrito geralmente para que outras arquiteturas não sejam muito diferentes. A próxima parte é a parte independente da máquina do Linuxulator. Esta seção abrange apenas o tratamento de i386 e ELF. A.OUT está obsoleto e não foi testado.</para>
<sect2 xml:id="syscall-handling">
<title>Manipulação de Syscall</title>
<para>A manipulação de Syscall é principalmente escrita em <filename>linux_sysvec.c</filename>, que cobre a maioria das rotinas apontadas na estrutura <literal>sysentvec</literal>. Quando um processo <trademark class="registered">Linux</trademark> executado no FreeBSD emite um syscall, a rotina syscall geral chama a rotina prepsyscall do linux para a ABI do <trademark class="registered">Linux</trademark>.</para>
<sect3 xml:id="linux-prepsyscall">
<title><trademark class="registered">Linux</trademark> prepsyscall</title>
<para><trademark class="registered">Linux</trademark> passa argumentos via registradores de syscalls (isso porque ele é limitado a 6 parametros no i386) enquanto o FreeBSD usa uma pilha. A rotina prepsyscall do <trademark class="registered">Linux</trademark> deve copiar parametros dos registradores para a pilha. A ordem dos registradores é: <varname>%ebx</varname>, <varname>%ecx</varname>, <varname>%edx</varname>, <varname>%esi</varname>, <varname>%edi</varname>, <varname>%ebp</varname>. O fato é que isso é verdadeiro apenas para <emphasis>a maioria</emphasis> das syscalls. Algumas (mais provavelmente <function>clone</function>) usam uma ordem diferente, mas é demasiadamente facil de arrumar inserindo um parametro dummy no prototype <function>linux_clone</function>.</para>
</sect3>
<sect3 xml:id="syscall-writing">
<title>Escrevendo syscall</title>
<para>Cada syscall implementada no Linuxulator deve ter seu protótipo com vários flags no <filename>syscalls.master</filename>. A forma do arquivo é:</para>
<programlisting>...
AUE_FORK STD { int linux_fork(void); }
...
AUE_CLOSE NOPROTO { int close(int fd); }
...</programlisting>
<para>A primeira coluna representa o número da syscall. A segunda coluna é para suporte de auditoria. A terceira coluna representa o tipo da syscall. É <literal>STD</literal>, <literal>OBSOL</literal>, <literal>NOPROTO</literal> e <literal>UNIMPL</literal>. <literal>STD</literal> é uma syscall padrão com protótipo e implementação completos. <literal>OBSOL</literal> é obsoleto e define apenas o protótipo. <literal>NOPROTO</literal> significa que a syscall é implementado em outro lugar, portanto, não precede o prefixo da ABI, etc. <literal>UNIMPL</literal> significa que a syscall será substituída pela syscall <function>nosys</function> (uma syscall apenas imprime uma mensagem sobre a syscall não sendo implementado e retornando <literal>ENOSYS</literal>).</para>
<para>De um script <filename>syscalls.master</filename>, gera três arquivos: <filename>linux_syscall.h</filename>, <filename>linux_proto.h</filename> e <filename>linux_sysent.c</filename>. O <filename>linux_syscall.h</filename> contém definições de nomes de syscall e seus valores numéricos, por exemplo:</para>
<programlisting>...
#define LINUX_SYS_linux_fork 2
...
#define LINUX_SYS_close 6
...</programlisting>
<para>O <filename>linux_proto.h</filename> contém definições de estrutura de argumentos para cada syscall, por exemplo:</para>
<programlisting>struct linux_fork_args {
register_t dummy;
};</programlisting>
<para>E finalmente, <filename>linux_sysent.c</filename> contém uma estrutura descrevendo a tabela de entrada do sistema, usada para realmente enviar um syscall, por exemplo:</para>
<programlisting>{ 0, (sy_call_t *)linux_fork, AUE_FORK, NULL, 0, 0 }, /* 2 = linux_fork */
{ AS(close_args), (sy_call_t *)close, AUE_CLOSE, NULL, 0, 0 }, /* 6 = close */</programlisting>
<para>Como você pode ver, <function>linux_fork</function> é implementado no próprio Linuxulator, então a definição é do tipo <literal>STD</literal> e não possui argumento, que é exibido pela estrutura de argumento fictícia. Por outro lado, <function>close</function> é apenas um apelido para o verdadeiro <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> do FreeBSD para que ele não possua estrutura de argumentos do linux associada e na tabela de entrada do sistema ele não é prefixado com linux, pois ele chama o verdadeiro <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> no kernel.</para>
</sect3>
<sect3 xml:id="dummy-syscalls">
<title>Dummy syscalls</title>
<para>A camada de emulação do <trademark class="registered">Linux</trademark> não está completa, pois algumas syscalls não estão implementadas corretamente e algumas não estão implementadas. A camada de emulação emprega um recurso para marcar syscalls não implementadas com a macro <literal>DUMMY</literal>. Estas definições fictícias residem em <filename>linux_dummy.c</filename> em uma forma de <literal>DUMMY(syscall); </literal>, que é então traduzido para vários arquivos auxiliares de syscall e a implementação consiste em imprimir uma mensagem dizendo que esta syscall não está implementada. O protótipo <literal>UNIMPL</literal> não é usado porque queremos ser capazes de identificar o nome da syscall que foi chamado para saber o que é mais importante implementar na syscalls.</para>
</sect3>
</sect2>
<sect2 xml:id="signal-handling">
<title>Manuseio de signals</title>
<para>A manipulação de sinais é feita geralmente no kernel do FreeBSD para todas as compatibilidades binárias com uma chamada para uma camada dependente de compatibilidade. A camada de compatibilidade do <trademark class="registered">Linux</trademark> define a <function> rotina linux_sendsig </function> para essa finalidade.</para>
<sect3 xml:id="linux-sendsig">
<title><trademark class="registered">Linux</trademark> sendsig</title>
<para>Esta rotina primeiro verifica se o signal foi instalado com um <literal>SA_SIGINFO</literal>, caso em que chama a rotina <function>linux_rt_sendsig</function>. Além disso, ele aloca (ou reutiliza um contexto de identificador de sinal já existente) e cria uma lista de argumentos para o manipulador de signal. Ele traduz o número do signal baseado na tabela de tradução do signal, atribui um manipulador, traduz o sigset. Em seguida, ele salva o contexto para a rotina <function>sigreturn</function> (vários registradores, número da trap traduzida e máscara de signal). Finalmente, copia o contexto do signal para o espaço do usuário e prepara o contexto para que o manipulador de sinal real seja executado.</para>
</sect3>
<sect3 xml:id="linux-rt-sendsig">
<title>linux_rt_sendsig</title>
<para>Esta rotina é similar a <function>linux_sendsig</function> apenas a preparação do contexto do sinal é diferente. Adiciona <literal>siginfo</literal>, <literal>ucontext</literal> e algumas partes do <trademark class="registered">POSIX</trademark>. Pode valer a pena considerar se essas duas funções não poderiam ser mescladas com um benefício de menos duplicação de código e, possivelmente, até mesmo execução mais rápida.</para>
</sect3>
<sect3 xml:id="linux-sigreturn">
<title>linux_sigreturn</title>
<para>Esta syscall é usada para retornar do manipulador de sinal. Ela faz algumas verificações de segurança e restaura o contexto do processo original. Também desmascara o sinal na máscara de sinal do processo.</para>
</sect3>
</sect2>
<sect2 xml:id="ptrace">
<title>Ptrace</title>
<para>Muitos derivados do <trademark class="registered">UNIX</trademark> implementam a syscall <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> para permitir vários recursos de rastreamento e depuração . Esse recurso permite que o processo de rastreamento obtenha várias informações sobre o processo rastreado, como registros de despejos, qualquer memória do espaço de endereço do processo, etc. e também para rastrear o processo, como em uma instrução ou entre entradas do sistema (syscalls e traps). <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> também permite definir várias informações no processo de rastreamento (registros, etc.). <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> é um padrão de toda o <trademark class="registered">UNIX</trademark> implementado na maioria dos <trademark class="registered">UNIX</trademark>es em todo o mundo.</para>
<para>Emulação do <trademark class="registered">Linux</trademark> no FreeBSD implementa a habilidade <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> em <filename>linux_ptrace.c</filename>. As rotinas para converter registradores entre <trademark class="registered">Linux</trademark> and FreeBSD e a atual emulação de syscall, syscall <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>. A syscall é um longo bloco de trocas que implementa em contraparte no FreeBSD para todo comando <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Os comandos <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> são em sua maioria igual entre <trademark class="registered">Linux</trademark> e FreeBSD então uma pequena modificação é necessária. Por exemplo, <literal>PT_GETREGS</literal> em <trademark class="registered">Linux</trademark> opera diretamente dos dados enquanto o FreeBSD usa um ponteiro para o dado e depois performa a syscall <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> (nativa), uma cópia deve ser feita pra preservar a semantica do <trademark class="registered">Linux</trademark>.</para>
<para>A implementação de <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> no Linuxulator tem algumas fraquezas conhecidas. Houve pânico ao usar o <command>strace</command> (que é um consumidor <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>) no ambiente Linuxulator. <literal>PT_SYSCALL</literal> também não está implementado.</para>
</sect2>
<sect2 xml:id="traps">
<title>Armadilhas (Traps)</title>
<para>Sempre que um processo <trademark class="registered">Linux</trademark> executado na camada de emulação captura a própria trap, ela é tratada de forma transparente com a única exceção da tradução de trap. <trademark class="registered">Linux</trademark> e o FreeBSD difere de opinião sobre o que é uma trap, então isso é tratado aqui. O código é realmente muito curto:</para>
<programlisting>static int
translate_traps(int signal, int trap_code)
{
if (signal != SIGBUS)
return signal;
switch (trap_code) {
case T_PROTFLT:
case T_TSSFLT:
case T_DOUBLEFLT:
case T_PAGEFLT:
return SIGSEGV;
default:
return signal;
}
}</programlisting>
</sect2>
<sect2 xml:id="stack-fixup">
<title>Correção de pilha</title>
<para>O editor de links em tempo de execução do RTLD espera as chamadas tags AUX na pilha durante uma <function>execve</function>, portanto, uma correção deve ser feita para garantir isso. Naturalmente, cada sistema RTLD é diferente, portanto, a camada de emulação deve fornecer sua própria rotina de correção de pilha para fazer isso. O mesmo acontece com o Linuxulator. O <function>elf_linux_fixup</function> simplesmente copia tags AUX para a pilha e ajusta a pilha do processo de espaço do usuário para apontar logo após essas tags. Então, a RTLD funciona de maneira inteligente.</para>
</sect2>
<sect2 xml:id="aout-support">
<title>Suporte para A.OUT</title>
<para>A camada de emulação <trademark class="registered">Linux</trademark> em i386 também suporta os binários <trademark class="registered">Linux</trademark> A.OUT. Praticamente tudo o que foi descrito nas seções anteriores deve ser implementado para o suporte A.OUT (além da tradução de traps e o envio de sinais). O suporte para binários A.OUT não é mais mantido, especialmente a emulação 2.6 não funciona com ele, mas isso não causa nenhum problema, já que os ports linux-base provavelmente não suportam binários A.OUT. Esse suporte provavelmente será removido no futuro. A maioria das coisas necessárias para carregar os binários <trademark class="registered">Linux</trademark> A.OUT está no arquivo <filename>imgact_linux.c</filename>.</para>
</sect2>
</sect1>
<sect1 xml:id="mi">
<title>Parte da amada de emulação -MI do <trademark class="registered">Linux </trademark> </title>
<para>Esta seção fala sobre parte independente de máquina do Linuxulator. Ele cobre a infra-estrutura de emulação necessária para a emulação do <trademark class="registered">Linux</trademark> 2.6, a implementação do TLS (thread local storage) (no i386) e os futexes. Então falamos brevemente sobre algumas syscalls.</para>
<sect2 xml:id="nptl-desc">
<title>Descrição do NPTL</title>
<para>Uma das principais áreas de progresso no desenvolvimento do <trademark class="registered">Linux</trademark> 2.6 foi o threading. Antes do 2.6, o suporte ao threading <trademark class="registered">Linux</trademark> era implementado na biblioteca <application>linuxthreads</application>. A biblioteca foi uma implementação parcial do threading <trademark class="registered">POSIX</trademark>. A segmentação foi implementada usando processos separados para cada threading usando a syscall <function>clone</function> para permitir que eles compartilhem o espaço de endereço (e outras coisas). A principal fraqueza desta abordagem era que cada thread tinha um PID diferente, o tratamento de sinal era quebrado (da perspectiva pthreads), etc. O desempenho também não era muito bom (uso de sinais <literal>SIGUSR</literal> para sincronização de threads) , consumo de recursos do kernel, etc.) para superar esses problemas, um novo sistema de threading foi desenvolvido e denominado NPTL.</para>
<para>A biblioteca NPTL focou em duas coisas, mas uma terceira coisa apareceu, então é normalmente considerada parte do NPTL. Essas duas coisas eram a incorporação de threads em uma estrutura de processo e futexes. A terceira coisa adicional foi o TLS, que não é diretamente exigido pelo NPTL, mas toda a biblioteca de usuário do NPTL depende dele. Essas melhorias resultaram em muito melhor desempenho e conformidade com os padrões. O NPTL é uma biblioteca de threading padrão nos sistemas <trademark class="registered">Linux</trademark> atualmente.</para>
<para>A implementação do FreeBSD Linuxulator se aproxima do NPTL em três áreas principais. O TLS, futexes e PID mangling, que serve para simular as threadings <trademark class="registered">Linux</trademark>. Outras seções descrevem cada uma dessas áreas.</para>
</sect2>
<sect2 xml:id="linux26-emu">
<title>Infra-estrutura de emulação do <trademark class="registered">Linux</trademark> 2.6</title>
<para>Estas seções tratam da maneira como as threadings <trademark class="registered">Linux</trademark> são gerenciadas e como nós simulamos isso no FreeBSD.</para>
<sect3 xml:id="linux26-runtime">
<title>Determinação de tempo de execução de emulação 2.6</title>
<para>A camada de emulação do <trademark class="registered">Linux</trademark> no FreeBSD suporta a configuração de tempo de execução da versão emulada. Isso é feito via <citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>, a saber <literal>compat.linux.osrelease</literal>. A configuração dessa <citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> afeta o comportamento de tempo de execução da camada de emulação. Quando definido como 2.6.x, ele configura o valor de <literal>linux_use_linux26</literal> enquanto a configuração para algo mais o mantém não definido. Essa variável (mais variáveis !!por prisão do mesmo tipo) determina se a infraestrutura 2.6 (principalmente o PID) é usada no código ou não. A configuração da versão é feita em todo o sistema e isso afeta todos os processos <trademark class="registered">Linux</trademark>. A <citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> não deve ser alterada ao executar qualquer binário do <trademark class="registered">Linux</trademark>, pois pode causar danos .</para>
</sect3>
<sect3 xml:id="linux-proc-thread">
<title>Processos e identificadores de threading <trademark class="registered">Linux</trademark></title>
<para>A semântica de threading <trademark class="registered">Linux</trademark> é um pouco confusa e usa uma nomenclatura inteiramente diferente do FreeBSD. Um processo em <trademark class="registered">Linux</trademark> consiste em uma <literal>struct task</literal> incorporando dois campos identificadores - PID e TGID. O PID <emphasis>não é</emphasis> um ID de processo, mas é um ID de thread. O TGID identifica um grupo de threads em outras palavras, um processo. Para o processo single-threaded, o PID é igual ao TGID.</para>
<para>A thread no NPTL é apenas um processo comum que acontece de ter TGID diferente de PID e ter um líder de grupo diferente de si mesmo (e VM compartilhada, é claro). Tudo o mais acontece da mesma maneira que em um processo comum. Não há separação de um status compartilhado para alguma estrutura externa como no FreeBSD. Isso cria alguma duplicação de informações e possível inconsistência de dados. O kernel <trademark class="registered">Linux</trademark> parece usar a tarefa -&gt; grupo de informações em alguns lugares e informações de tarefas em outros lugares e isso não é muito consistente e parece propenso a erros.</para>
<para>Cada threading NPTL é criada por uma chamada a syscall <function>clone</function> com um conjunto específico de flags (mais na próxima subseção). O NPTL implementa segmentação rígida de 1:1.</para>
<para>No FreeBSD nós emulamos threads NPTL com processos comuns do FreeBSD que compartilham espaço de VM, etc. e a ginástica PID é apenas imitada na estrutura específica de emulação anexada ao processo. A estrutura anexada ao processo se parece com:</para>
<programlisting>struct linux_emuldata {
pid_t pid;
int *child_set_tid; /* in clone(): Child.s TID to set on clone */
int *child_clear_tid;/* in clone(): Child.s TID to clear on exit */
struct linux_emuldata_shared *shared;
int pdeath_signal; /* parent death signal */
LIST_ENTRY(linux_emuldata) threads; /* list of linux threads */
};</programlisting>
<para>O PID é usado para identificar o processo do FreeBSD que liga esta estrutura. <function> child_se_tid </function> e <function> child_clear_tid </function> são usadas para cópia do endereço TID quando um processo existe e é criado. O ponteiro <varname>shared</varname> aponta para uma estrutura compartilhada entre as threads. A variável <varname>pdeath_signal</varname> identifica o sinal de morte do processo pai e o ponteiro <varname>threads</varname> é usado para vincular essa estrutura à lista de threads. A estrutura <literal>linux_emuldata_shared</literal> se parece com:</para>
<programlisting>struct linux_emuldata_shared {
int refs;
pid_t group_pid;
LIST_HEAD(, linux_emuldata) threads; /* head of list of linux threads */
};</programlisting>
<para>O <varname>refs</varname> é um contador de referência sendo usado para determinar quando podemos liberar a estrutura para evitar vazamentos de memória. O <varname>group_pid</varname> é para identificar o PID (=TGID) de todo o processo (=grupo de threads). O ponteiro <varname>threads</varname> é o cabeçalho da lista de threading no processo.</para>
<para>A estrutura <literal>linux_emuldata</literal> pode ser obtida a partir do processo usando <function>em_find</function>. O protótipo da função é:</para>
<programlisting>struct linux_emuldata * em_find (struct proc *, int bloqueado);</programlisting>
<para>Aqui, <varname>proc</varname> é o processo em que queremos a estrutura emuldata e o parâmetro locked determina se queremos ou não bloquear. Os valores aceitos são <literal>EMUL_DOLOCK</literal> e <literal>EMUL_DOUNLOCK</literal>. Mais sobre o bloqueio mais tarde.</para>
</sect3>
<sect3 xml:id="pid-mangling">
<title>Maqueando PID</title>
<para>Por causa da visão diferente descrita sabendo o que é um ID de processo e ID de thread entre o FreeBSD e o <trademark class="registered">Linux</trademark> nós temos que traduzir a view de alguma forma. Nós fazemos isso pelo manuseio do PID. Isto significa que nós falsificamos o que um PID (=TGID) e um TID (=PID) é entre o kernel e o userland. A regra é que no kernel (no Linuxulator) PID=PID e TGID=grupo de id -&gt; compartilhado e para userland nós apresentamos <literal>PID=shared -&gt; group_pid </literal> e <literal>TID=proc -&gt; p_pid</literal>. O membro PID da estrutura <literal>linux_emuldata </literal> é um PID do FreeBSD.</para>
<para>O acima afeta principalmente syscalls getyscl, getppid, gettid. Onde usamos PID/TGID, respectivamente. Em cópia de TIDs em <function>child_clear_tid</function> e <function>child_set_tid</function> copiamos o PID FreeBSD.</para>
</sect3>
<sect3 xml:id="clone-syscall">
<title>syscall Clone</title>
<para>A syscall <function>clone</function> é o modo como as threads são criadas no <trademark class="registered">Linux</trademark>. O protótipo syscall é assim:</para>
<programlisting>int linux_clone(l_int flags, void *stack, void *parent_tidptr, int dummy,
void * child_tidptr);</programlisting>
<para>O parâmetro <varname>flags</varname> informa a syscall como exatamente os processos devem ser clonados. Como descrito acima, o <trademark class="registered">Linux</trademark> pode criar processos compartilhando várias coisas independentemente, por exemplo, dois processos podem compartilhar file descriptors, mas não VM, etc. Ultimo byte do parametro <varname>flags</varname> é o sinal de saída do processo recém-criado. O parâmetro <varname>stack</varname> se não <literal>NULL</literal> diz, onde está a pilha de threading e se é <literal>NULL</literal> nós devemos copiar-na-escrita chamando a pilha de processos (isto é, faz a rotina normal de <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>). O parâmetro <varname>parent_tidptr</varname> é usado como um endereço para copiar o PID do processo (ou seja, o id do thread), uma vez que o processo esteja suficientemente instanciado, mas ainda não seja executável. O parâmetro <varname>dummy</varname> está aqui devido à convenção de chamada muito estranha desta syscall em i386. Ele usa os registradores diretamente e não deixa o compilador fazer o que resulta na necessidade de uma syscall falsa. O parâmetro <varname>child_tidptr</varname> é usado como um endereço para copiar o PID assim que o processo terminar de bifurcar e quando o processo terminar.</para>
<para>O syscall prossegue definindo flags correspondentes dependendo dos flags passadas. Por exemplo, mapas <literal>CLONE_VM</literal> para RFMEM (compartilhamento de VM), etc. O único nit aqui é <literal>CLONE_FS</literal> e <literal>CLONE_FILES</literal> porque o FreeBSD não permite configurar isso separadamente, então nós o falsificamos não configurando RFFDG (copiando a tabela fd e outras informações fs) se qualquer uma delas estiver definida. Isso não causa nenhum problema, porque essas flags são sempre definidas juntas. Depois de definir as flags, o processo é bifurcado usando a rotina <function>fork1</function> interna, o processo é instrumentado para não ser colocado em uma fila de execução, ou seja, não deve ser definido como executável. Depois que a bifurcação é feita, possivelmente reparamos o processo recém-criado para emular a semântica <literal>CLONE_PARENT</literal>. A próxima parte está criando os dados de emulação. Threads no <trademark class="registered">Linux</trademark> não sinalizam seus processos pais, então nós definimos o sinal de saída como 0 para desabilitar isso. Depois que a configuração de <varname>child_set_tid</varname> e <varname>child_clear_tid</varname> é executada, habilitando a funcionalidade posteriormente no código. Neste ponto, copiamos o PID para o endereço especificado por <varname>parent_tidptr</varname>. A configuração da pilha de processos é feita simplesmente reescrevendo o registro do quadro de linha <varname>% esp</varname> (<varname>% rsp</varname> no amd64). A próxima parte é configurar o TLS para o processo recém-criado. Depois disso, a semântica <citerefentry><refentrytitle>vfork</refentrytitle><manvolnum>2</manvolnum></citerefentry> pode ser emulada e, finalmente, o processo recém-criado é colocado em uma fila de execução e copiando seu PID para o processo pai através do valor de retorno <function>clone</function> é feito.</para>
<para>A syscall <function>clone</function> é capaz e de fato é usado para emulação de syscalls <citerefentry><refentrytitle>fork</refentrytitle><manvolnum/></citerefentry> e <citerefentry><refentrytitle>vfork</refentrytitle><manvolnum>2</manvolnum></citerefentry>. O glibc mais novo em um caso de kernel 2.6 usa o <function>clone</function> para implementar syscalls <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> e <citerefentry><refentrytitle>vfork</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
</sect3>
<sect3 xml:id="locking">
<title>Bloqueio</title>
<para>O bloqueio é implementado como per-subsystem porque não esperamos muita disputa sobre eles. Existem dois bloqueios: <literal>emul_lock</literal> usado para proteger a manipulação de <literal>linux_emuldata</literal> e <literal>emul_shared_lock</literal> usado para manipular <literal>linux_emuldata_shared</literal>. O <literal>emul_lock</literal> é um mutex bloqueador não tolerável, enquanto <literal>emul_shared_lock</literal> é um bloqueio travável <literal>sx_lock</literal>. Devido ao bloqueio por subsistema, podemos unir alguns bloqueios e é por isso que o em-find oferece o acesso sem bloqueio.</para>
</sect3>
</sect2>
<sect2 xml:id="tls">
<title>TLS</title>
<para>Esta seção trata do TLS também conhecido como armazenamento local de thread.</para>
<sect3 xml:id="trheading-intro">
<title>Introdução ao threading</title>
<para>Threads na ciência da computação são entidades com um processo que podem ser agendados independentemente de qualquer outro. As threads nos processos compartilham amplos dados de processos (file descriptors, etc.) mas também tem sua prŕopria pilha para seus próprios dados. Algumas vezes é preciso para um processamento amplo de dados dado uma thread. Imagine um nome de uma thread algo assim. A tradicional API de threading do <trademark class="registered">UNIX</trademark>, <application>pthreads</application> prove um caminho para isso em <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> onde a thread pode criar uma chave para os dados da thread local <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> ou <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> para manipular esses dados. Você pode ver que esse não é o caminho mais confortavel que poderia ser usado. Então varios produtores de compiladores C/C++ introduziram um caminho melhor. Eles definiram uma nova chave modificadora de thread que especifica que a variavel é especifica de uma thread. Um novo método de acessar as variaveis foi desenvolvio como (ao menos no i386). O método <application>pthreads</application> tende a ser implementado no espaço de usuário como uma tabela de lookup trivial. A performance como uma solução não é muito boa. Então o novo método (no i386) registradores de segmentos para endereçar um segmento, onde a área do TLS é armazenada, então o atual acesso da variável de uma thread é apenas adicionada ao registrador de segmentos para o endereçamento via it. Os registradores de segmentos são usualmente <varname>%gs</varname> e <varname>%fs</varname> agindo como seletores de segmento. Toda thread tem sua própria área onde os dados da thread local são armazenados e o segmento deve ser carregado em toda troca de contexto. Esse método é muito rapido e usado em todo mundo em volta do <trademark class="registered">UNIX</trademark> i386. Ambos FreeBSD e <trademark class="registered">Linux</trademark> Implementam sua abordagem e seus resultados tem sido muito bons. Unico ponto negativo é ter que recarregar o segmento em toda troca de contexto que pode deixar o processo lento. FreeBSD tenta evitar essa sobrecarga usando apenas 1 descritor de segmento enquanto <trademark class="registered">Linux</trademark> usa 3. Interessante que isso quase nunca usa mais que 1 descritor (apenas o <application>Wine</application> parece usar 2) então o <trademark class="registered">Linux</trademark> paga esse preço desnecessário na troca de contexto.</para>
</sect3>
<sect3 xml:id="i386-segs">
<title>Segmentos em i386</title>
<para>A arquitetura i386 implementa os então chamados segmentos.Um segmento é uma descrição de um espaço na memória. A base de endereço (baixa) na area da memória, o fim disso (teto), tipo, proteção, etc. A memória descrita por um segmento pode ser acessada usando um seletor de segmento (<varname>%cs</varname>, <varname>%ds</varname>, <varname>%ss</varname>, <varname>%es</varname>, <varname>%fs</varname>, <varname>%gs</varname>). Por exemplo, deixe nos supor que temos um segmento com base no endereço 0x1234 e comprimento e esse codigo:</para>
<programlisting>mov %edx,%gs:0x10</programlisting>
<para>Isso carregará o conteúdo do registro <varname>% edx</varname> na localização da memória 0x1244. Alguns registradores de segmento têm um uso especial, por exemplo <varname>% cs</varname> é usado para segmento de código e <varname>% ss</varname> é usado para o segmento de pilha, mas <varname>% fs</varname> e <varname>% gs</varname> geralmente não são usados. Os segmentos são armazenados em uma tabela GDT global ou em uma tabela LDT local. O LDT é acessado por meio de uma entrada no GDT. O LDT pode armazenar mais tipos de segmentos. LDT pode ser por processo. Ambas as tabelas definem até 8191 entradas.</para>
</sect3>
<sect3 xml:id="linux-i386">
<title>Implementação no <trademark class="registered">Linux</trademark> i386</title>
<para>Existem duas maneiras principais de configurar o TLS no <trademark class="registered">Linux</trademark>. Pode ser definido ao clonar um processo usando a syscall <function>clone</function> ou ele pode chamar <function>set_thread_area</function>. Quando um processo passa a flag <literal>CLONE_SETTLS</literal> para <function>clone</function>, o kernel espera que a memória apontada pelo registrador <varname>% esi</varname> uma representação <trademark class="registered">Linux</trademark> do espaço do usuário de um segmento, que é traduzido para a representação da máquina de um segmento e carregado em um slot GDT. O slot GDT pode ser especificado com um número ou -1 pode ser usado, o que significa que o próprio sistema deve escolher o primeiro slot livre. Na prática, a grande maioria dos programas usa apenas uma entrada de TLS e não se importa com o número da entrada. Nós exploramos isso na emulação e dependemos disso.</para>
</sect3>
<sect3 xml:id="tls-emu">
<title>Emulação de TLS do <trademark class="registered">Linux</trademark></title>
<sect4 xml:id="tls-i386">
<title>i386</title>
<para>O carregamento de TLS para o segmento atual acontece chamando <function>set_thread_area</function> enquanto o TLS é carregado para um segundo processo em <function>clone</function> é feito no bloco separado em <function>clone</function>. Essas duas funções são muito semelhantes. A única diferença é o carregamento real do segmento GDT, que acontece na próxima troca de contexto para o processo recém-criado, enquanto <function>set_thread_area</function> deve carregar isso diretamente. O código basicamente faz isso. Ele copia o descritor de segmento de formulário <trademark class="registered">Linux</trademark> da área de usuário. O código verifica o número do descritor, mas como isso difere entre o FreeBSD e o <trademark class="registered">Linux</trademark>, maquiamos um pouco. Nós suportamos apenas índices de 6, 3 e -1. O número 6 é genuíno do <trademark class="registered">Linux</trademark>, 3 é genuíno do FreeBSD one e -1 significa uma auto seleção. Em seguida, definimos o número do descritor como constante 3 e copiamos isso para o espaço do usuário. Contamos com o processo em espaço de usuário usando o número do descritor, mas isso funciona na maior parte do tempo (nunca vi um caso em que isso não funcionou), como o processo em espaço de usuário normalmente passa em 1. Então, convertemos o descritor da classe do <trademark class="registered">Linux</trademark> para um formulário dependente da máquina (isto é, independente do sistema operacional) e copie isto para o descritor de segmento definido pelo FreeBSD. Finalmente podemos carregá-lo. Atribuímos o descritor às threads PCB (bloco de controle de processo) e carregamos o segmento <varname>% gs</varname> usando <function>load_gs</function>. Este carregamento deve ser feito em uma seção crítica para que nada possa nos interromper. O caso <literal>CLONE_SETTLS</literal> funciona exatamente como este, apenas o carregamento usando <function>load_gs</function> não é executado. O segmento usado para isso (segmento número 3) é compartilhado para este uso entre os processos do FreeBSD e do <trademark class="registered">Linux</trademark> para que a camada de emulação <trademark class="registered">Linux</trademark> não adicione nenhuma sobrecarga sobre o FreeBSD.</para>
</sect4>
<sect4 xml:id="tls-amd64">
<title>amd64</title>
<para>A implementação do amd64 é semelhante à do i386, mas inicialmente não havia um descritor de segmento de 32 bits usado para esse propósito (por isso nem usuários nativos de TLB de 32 bits trabalhavam), então tivemos que adicionar esse segmento e implementar seu carregamento em cada troca de contexto (quando a flag sinalizando uso de 32 bits está definida). Além disso, o carregamento de TLS é exatamente o mesmo, apenas os números de segmento são diferentes e o formato do descritor e o carregamento diferem ligeiramente.</para>
</sect4>
</sect3>
</sect2>
<sect2 xml:id="futexes">
<title>Futexes</title>
<sect3 xml:id="sync-intro">
<title>Introdução à sincronização</title>
<para>Threads precisam de algum tipo de sincronização e <trademark class="registered">POSIX</trademark> fornece alguns deles: mutexes para exclusão mútua, bloqueios de leitura/gravação para exclusão mútua com relação de polarização de leituras e gravações e variáveis !!de condição para sinalizar um mudança de status. É interessante observar que a API de thread <trademark class="registered">POSIX</trademark> não tem suporte para semáforos. Essas implementações de rotinas de sincronização são altamente dependentes do tipo de suporte a threading que temos. No modelo puro 1:M (espaço de usuário), a implementação pode ser feita apenas no espaço do usuário e, portanto, ser muito rápida (as variáveis !!de condição provavelmente serão implementadas usando sinais, ou seja, não rápido) e simples. No modelo 1:1, a situação também é bastante clara - as threading devem ser sincronizadas usando as facilidades do kernel (o que é muito lento porque uma syscall deve ser executada). O cenário M:N misto combina apenas a primeira e a segunda abordagem ou depende apenas do kernel. A sincronização de threads é uma parte vital da programação ativada por threads e seu desempenho pode afetar muito o programa resultante. Benchmarks recentes no sistema operacional FreeBSD mostraram que uma implementação sx_lock melhorada gerou 40% de aceleração no <firstterm>ZFS</firstterm> (um usuário sx pesado), isso é algo in-kernel, mas mostra claramente quão importante é o desempenho das primitivas de sincronização. .</para>
<para>Os programas em threading devem ser escritos com o mínimo de contenção possível em bloqueios. Caso contrário, em vez de fazer um trabalho útil, a threading apenas espera em um bloqueio. Devido a isso, os programas encadeados mais bem escritos mostram pouca contenção de bloqueios.</para>
</sect3>
<sect3 xml:id="futex-intro">
<title>Introdução a Futexes</title>
<para>O <trademark class="registered">Linux</trademark> implementa a segmentação 1:1, ou seja, tem de utilizar primitivas de sincronização no kernel. Como afirmado anteriormente, programas encadeados bem escritos possuem pouca contenção de bloqueio. Assim, uma sequência típica poderia ser executada como dois contador de referência de mutex de aumento/redução atômico, que é muito rápido, conforme apresentado pelo exemplo a seguir:</para>
<programlisting>pthread_mutex_lock(&amp;mutex);
....
pthread_mutex_unlock(&amp;mutex);</programlisting>
<para>O threading 1:1 nos força a executar dois syscalls para as chamadas mutex, o que é muito lento.</para>
<para>A solução que o <trademark class="registered">Linux</trademark> 2.6 implementa é chamada de futexes. Futexes implementam a verificação de contenção no espaço do usuário e chama primitivas do kernel apenas em um caso de contenção. Assim, o caso típico ocorre sem qualquer intervenção do kernel. Isso produz uma implementação de primitivas de sincronização razoavelmente rápida e flexível.</para>
</sect3>
<sect3 xml:id="futex-api">
<title>API do Futex</title>
<para>A syscall do futex é assim:</para>
<programlisting>int futex(void *uaddr, int op, int val, struct timespec *timeout, void *uaddr2, int val3);</programlisting>
<para>Neste exemplo <varname>uaddr</varname> é um endereço do mutex no espaço do usuário, <varname>op</varname> é uma operação que estamos prestes a executar e os outros parâmetros têm significado por operação.</para>
<para>Futexes implementam as seguintes operações:</para>
<itemizedlist>
<listitem>
<para><literal>FUTEX_WAIT</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_WAKE</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_FD</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_REQUEUE</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_CMP_REQUEUE</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_WAKE_OP</literal></para>
</listitem>
</itemizedlist>
<sect4 xml:id="futex-wait">
<title>FUTEX_WAIT</title>
<para>Esta operação verifica que no endereço <varname>uaddr</varname> o valor <varname>val</varname> é gravado. Se não, <literal>EWOULDBLOCK</literal> é retornado, caso contrário, a thread é enfileirada no futex e é suspensa. Se o argumento <varname>timeout</varname> for diferente de zero, ele especificará o tempo máximo para a suspensão, caso contrário, a suspensão será infinita.</para>
</sect4>
<sect4 xml:id="futex-wake">
<title>FUTEX_WAKE</title>
<para>Esta operação tem um futex em <varname>uaddr</varname> e acorda os primeiros futexes <varname>val</varname> enfileirados neste futex. </para>
</sect4>
<sect4 xml:id="futex-fd">
<title>FUTEX_FD</title>
<para>Esta operação associa um descritor de arquivo com um determinado futex.</para>
</sect4>
<sect4 xml:id="futex-requeue">
<title>FUTEX_REQUEUE</title>
<para>Esta operação pega threads <varname>val</varname> enfileirados no futex em <varname>uaddr</varname>, acorda-os e pega as próximas threads <varname>val2</varname> e enfileira-os no futex em <varname>uaddr2</varname>.</para>
</sect4>
<sect4 xml:id="futex-cmp-requeue">
<title>FUTEX_CMP_REQUEUE</title>
<para>Essa operação faz o mesmo que <literal>FUTEX_REQUEUE</literal>, mas verifica se <varname>val3</varname> é igual a <varname>val</varname> primeiro.</para>
</sect4>
<sect4 xml:id="futex-wake-op">
<title>FUTEX_WAKE_OP</title>
<para>Esta operação executa uma operação atômica em <varname>val3</varname> (que contém algum outro valor codificado) e <varname>uaddr</varname>. Então, ele acorda threads <varname>val</varname> em futex em <varname>uaddr</varname> e se a operação atômica retornar um número positivo, ele ativa os threadings <varname>val2</varname> em futex em <varname>uaddr2</varname>.</para>
<para>As operações implementadas em <literal>FUTEX_WAKE_OP</literal>:</para>
<itemizedlist>
<listitem>
<para><literal>FUTEX_OP_SET</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_OP_ADD</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_OP_OR</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_OP_AND</literal></para>
</listitem>
<listitem>
<para><literal>FUTEX_OP_XOR</literal></para>
</listitem>
</itemizedlist>
<note>
<para>Não existe um parâmetro <varname>val2</varname> no protótipo do futex. O <varname>val2</varname> é obtido do parâmetro <varname>struct timespec *timeout</varname> para as operações <literal>FUTEX_REQUEUE</literal>, <literal>FUTEX_CMP_REQUEUE</literal> e <literal>FUTEX_WAKE_OP</literal>.</para>
</note>
</sect4>
</sect3>
<sect3 xml:id="futex-emu">
<title>Emulação de Futex no FreeBSD</title>
<para>A emulação de futex no FreeBSD é retirada do NetBSD e posteriormente estendida por nós. Ele é colocado nos arquivos <filename>linux_futex.c</filename> e <filename>linux_futex.h</filename>. A estrutura <literal>futex</literal> se parece com:</para>
<programlisting>struct futex {
void *f_uaddr;
int f_refcount;
LIST_ENTRY(futex) f_list;
TAILQ_HEAD(lf_waiting_paroc, waiting_proc) f_waiting_proc;
};</programlisting>
<para>E a estrutura <literal>waiting_proc</literal> é:</para>
<programlisting>struct waiting_proc {
struct thread *wp_t;
struct futex *wp_new_futex;
TAILQ_ENTRY(waiting_proc) wp_list;
};</programlisting>
<sect4 xml:id="futex-get">
<title>futex_get / futex_put</title>
<para>Um futex é obtido usando a função <function>futex_get</function>, que busca uma lista linear de futexes e retorna o encontrado ou cria um novo futex. Ao liberar um futex do uso, chamamos a função <function>futex_put</function>, que diminui um contador de referência do futex e, se o refcount chegar a zero, ele é liberado.</para>
</sect4>
<sect4 xml:id="futex-sleep">
<title>futex_sleep</title>
<para>Quando um futex enfileira uma thread para dormir, ele cria uma estrutura <literal>working_proc</literal> e coloca essa estrutura na lista dentro da estrutura do futex, então apenas executa um <citerefentry><refentrytitle>tsleep</refentrytitle><manvolnum>9</manvolnum></citerefentry> para suspender a threading. O sleep pode ser expirado. Depois de <citerefentry><refentrytitle>tsleep</refentrytitle><manvolnum>9</manvolnum></citerefentry> retornar (a thread foi acordada ou expirou) a estrutura <literal>working_proc</literal> é removida da lista e é destruído. Tudo isso é feito na função <function>futex_sleep</function>. Se nós formos acordados de <function>futex_wake</function> nós temos <varname>wp_new_futex</varname> setado então nós dormimos nele. Desta forma, um novo enfileiramento é feito nesta função.</para>
</sect4>
<sect4 xml:id="futex-wake-2">
<title>futex_wake</title>
<para>Acordar uma thread em sleep em uma futex é performado na função <function>futex_wake</function>. Primeiro nesta função nós imitamos o comportamento estranho do <trademark class="registered">Linux</trademark>, onde ele acorda N threads para todas as operações, a única exceção é que as operações REQUEUE são executadas em threads N+1. Mas isso geralmente não faz diferença, pois estamos acordando todos as threads. Em seguida na função no loop nós acordamos n threads, depois disso nós checamos se existe um novo futex para requeuering. Se assim for, nós enfileiramos novamente até n2 threads no novo futex. Isso coopera com o <function>futex_sleep</function>.</para>
</sect4>
<sect4 xml:id="futex-wake-op-2">
<title>futex_wake_op</title>
<para>A operação <literal>FUTEX_WAKE_OP</literal> é bastante complicada. Primeiro nós obtemos dois futexes nos endereços <varname>uaddr</varname> e <varname>uaddr2</varname> e então executamos a operação atômica usando <varname>val3</varname> e <varname>uaddr2</varname>. Então os waiters <varname>val</varname> no primeiro futex são acordados e se a condição de operação atômica se mantém, nós acordamos o waiter <varname>val2</varname> (ex <varname>timeout</varname>) no segundo futex.</para>
</sect4>
<sect4 xml:id="futex-atomic-op">
<title>operação atômica futex</title>
<para>A operação atômica usa dois parâmetros <varname>encoded_op</varname> e <varname>uaddr</varname>. A operação codificada, codifica a operação em si, comparando valor, argumento de operação e argumento de comparação. O pseudocódigo da operação é como este:</para>
<programlisting>oldval = *uaddr2
*uaddr2 = oldval OP oparg</programlisting>
<para>E isso é feito atomicamente. Primeiro, uma cópia do número em <varname>uaddr</varname> é executada e a operação é concluída. O código manipula falhas de página e, se nenhuma falha de página ocorrer, <varname>oldval</varname> é comparado ao argumento <varname>cmparg</varname> com o comparador cmp.</para>
</sect4>
<sect4 xml:id="futex-locking">
<title>Bloqueio Futex</title>
<para>A implementação do Futex usa duas listas de lock que protegndo <function>sx_lock</function> e locks globais (Giant ou outra <function>sx_lock</function>). Cada operação é executada bloqueada desde o início até o final.</para>
</sect4>
</sect3>
</sect2>
<sect2 xml:id="syscall-impl">
<title>Implementação de várias syscalls</title>
<para>Nesta seção, descreverei algumas syscalls menores que merecem destaque, pois sua implementação não é óbvia ou as syscalls são interessantes de outro ponto de vista.</para>
<sect3 xml:id="syscall-at">
<title>*na família de syscalls</title>
<para>Durante o desenvolvimento do kernel 2.6.16 do <trademark class="registered">Linux</trademark>, os *at syscalls foram adicionados. Essas syscalls (<function>openat</function>, por exemplo) funcionam exatamente como suas contrapartes sem-menos, com a pequena exceção do parâmetro <varname>dirfd</varname>. Este parâmetro muda onde o arquivo dado, no qual a syscall deve ser executado, está. Quando o parâmetro <varname>filename</varname> é absoluto <varname>dirfd</varname> é ignorado, mas quando o caminho para o arquivo é relativo, ele é checado. O parâmetro <varname>dirfd</varname> é um diretório relativo ao qual o nome do caminho relativo é verificado. O parâmetro <varname>dirfd</varname> é um file descriptor de algum diretório ou <literal>AT_FDCWD</literal>. Então, por exemplo, a syscall <function>openat</function> pode ser assim:</para>
<programlisting>file descriptor 123 = /tmp/foo/, current working directory = /tmp/
openat(123, /tmp/bah\, flags, mode) /* opens /tmp/bah */
openat(123, bah\, flags, mode) /* opens /tmp/foo/bah */
openat(AT_FDWCWD, bah\, flags, mode) /* opens /tmp/bah */
openat(stdio, bah\, flags, mode) /* returns error because stdio is not a directory */</programlisting>
<para>Esta infra-estrutura é necessária para evitar corridas ao abrir arquivos fora do diretório de trabalho. Imagine que um processo consiste em duas threads, thread A e thread B. Thread A emite <literal>open (./tmp/foo/bah., Flags, mode)</literal> e antes de retornar ele se antecipa e a thread B é executada. A thread B não se preocupa com as necessidades da thread A e renomeia ou remove o <filename>/tmp/foo/</filename>. Nós temos uma corrida. Para evitar isso, podemos abrir o <filename>/tmp/foo</filename> e usá-lo como <varname>dirfd</varname> para a syscall <function>openat</function>. Isso também permite que o usuário implemente diretórios de trabalho por thread.</para>
<para>A família do <trademark class="registered">Linux</trademark> de *at syscalls contém: <function>linux_openat</function>, <function>linux_mkdirat</function>, <function>linux_mknodat</function>, <function>linux_fchownat</function>, <function>linux_futimesat</function>, <function>linux_fstatat64</function>, <function>linux_unlinkat</function>, <function>linux_renameat</function>, <function>linux_linkat</function> , <function>linux_symlinkat</function>, <function>linux_readlinkat</function>, <function>linux_fchmodat</function> e <function>linux_faccessat</function>. Tudo isso é implementado usando a rotina modificada <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> e a simples camada de quebra automática.</para>
<sect4 xml:id="implementation">
<title>Implementação</title>
<para>A implementação é feita alterando a rotina <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> (descrita acima) para obter o parâmetro adicional <varname>dirfd</varname> no sua estrutura <literal>nameidata</literal> , que especifica o ponto inicial da pesquisa do nome do caminho, em vez de usar o diretório de trabalho atual todas as vezes. A resolução de <varname>dirfd</varname> do número do file descriptor para um vnode é feita em *at syscalls nativo. Quando <varname>dirfd</varname> é <literal>AT_FDCWD</literal>, a entrada <varname>dvp</varname> na estrutura <literal>nameidata</literal> é <literal>NULL</literal>, mas <varname>dirfd</varname> é um número diferente, obtemos um arquivo para este file descriptor, verificamos se este arquivo é válido e se há vnode anexado a ele, então obtemos um vnode. Então nós verificamos este vnode por ser um diretório. Na rotina real <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> simplesmente substituímos a variável <varname>dvp</varname> vnode pela variável <varname>dp</varname> na função <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry>, que determina o ponto de partida. O <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> não é usado diretamente, mas através de um rastreamento de diferentes funções em vários níveis. Por exemplo, o <function>openat</function> é assim:</para>
<programlisting>openat() --&gt; kern_openat() --&gt; vn_open() -&gt; namei()</programlisting>
<para>Por esse motivo, <function>kern_open</function> e <function>vn_open</function> devem ser alterados para incorporar o parâmetro <varname>dirfd</varname> adicional. Nenhuma camada de compatibilidade é criada para esses, porque não há muitos usuários disso e os usuários podem ser facilmente convertidos. Esta implementação geral permite ao FreeBSD implementar suas próprias *at syscalls. Isso está sendo discutido agora.</para>
</sect4>
</sect3>
<sect3 xml:id="ioctl">
<title>Ioctl</title>
<para>A interface ioctl é bastante frágil devido à sua generalidade. Nós temos que ter em mente que os dispositivos diferem entre <trademark class="registered">Linux</trademark> e FreeBSD, então alguns cuidados devem ser aplicados para fazer o trabalho de emulação de ioctl corretamente. O manuseio ioctl é implementado em <filename>linux_ioctl.c</filename>, onde a função <function>linux_ioctl</function> é definida. Esta função simplesmente itera sobre conjuntos de manipuladores ioctl para encontrar um manipulador que implementa um dado comando. A syscall ioctl tem três parâmetros, o file descriptor, comando e um argumento. O comando é um número de 16 bits, que, em teoria, é dividido em alta classe determinante de 8 bits do comando ioctl e 8 bits baixos, que são o comando real dentro do conjunto dado. A emulação aproveita essa divisão. Implementamos manipuladores para cada conjunto, como <function>sound_handler</function> ou <function>disk_handler</function>. Cada manipulador tem um comando máximo e um comando mínimo definido, que é usado para determinar qual manipulador é usado. Existem pequenos problemas com esta abordagem porque <trademark class="registered">Linux</trademark> não usa a divisão definida consistentemente, por isso as ioctls para um conjunto diferente estão dentro de um conjunto ao qual não devem pertencer (ioctls genéricos SCSI dentro do cdrom conjunto, etc.). O FreeBSD atualmente não implementa muitos ioctls do <trademark class="registered">Linux</trademark> (comparado ao NetBSD, por exemplo), mas o plano é portar os do NetBSD. A tendência é usar o ioctls <trademark class="registered">Linux</trademark> mesmo nos drivers nativos do FreeBSD, devido à fácil portabilidade dos aplicativos.</para>
</sect3>
<sect3 xml:id="debugging">
<title>Depuração</title>
<para>Cada syscall deve ser debugável. Para isso, introduzimos uma pequena infra-estrutura. Nós temos o recurso ldebug, que informa se uma dada syscall deve ser depurada (configurável através de um sysctl). Para impressão, temos as macros LMSG e ARGS. Essas são usadas !!para alterar uma string imprimível para mensagens uniformes de depuração.</para>
</sect3>
</sect2>
</sect1>
<sect1 xml:id="conclusion">
<title>Conclusão</title>
<sect2 xml:id="results">
<title>Resultados</title>
<para>Em abril de 2007, a camada de emulação do <trademark class="registered">Linux</trademark> é capaz de emular o kernel <trademark class="registered">Linux</trademark> 2.6.16 muito bem. Os problemas remanescentes dizem respeito a futexes, inacabado na família de syscalls *at, entrega de sinais problemáticos, falta de <function>epoll</function> e <function>inotify</function> e provavelmente alguns bugs que ainda não descobrimos. Apesar disso, somos capazes de executar basicamente todos os programas <trademark class="registered">Linux</trademark> incluídos na coleção de ports do FreeBSD com o Fedora Core 4 em 2.6.16 e há alguns relatos rudimentares de sucesso com o Fedora Core 6 em 2.6.16. O linux_base do Fedora Core 6 foi recentemente comprometido permitindo alguns testes adicionais da camada de emulação e nos dando mais algumas dicas onde devemos nos esforçar para implementar o material que está faltando.</para>
<para>Nós podemos rodar os aplicativos mais usados !!como o <package>www/linux-firefox</package>, <package>www/linux-opera</package>, <package>net-im/skype</package> e alguns jogos da coleção dos ports. Alguns dos programas exibem mau comportamento na emulação 2.6, mas isso está atualmente sob investigação e, espera-se, será corrigido em breve. A única grande aplicação que se sabe que não funciona é o <trademark>Java</trademark> Development Kit do <trademark class="registered">Linux</trademark> e isto é devido ao requisito de <function>epoll</function> habilidade que não está diretamente relacionada ao kernel do <trademark class="registered">Linux</trademark> 2.6.</para>
<para>Esperamos habilitar a emulação 2.6.16 por padrão algum tempo depois que o FreeBSD 7.0 for lançado pelo menos para expor as partes da emulação 2.6 para alguns testes mais amplos. Feito isso, podemos mudar para o Fedora Core 6 linux_base, que é o plano final.</para>
</sect2>
<sect2 xml:id="future-work">
<title>Trabalho futuro</title>
<para>O trabalho futuro deve focar na correção dos problemas remanescentes com futexes, implementar o restante da família de syscalls, corrigir a entrega de sinal e possivelmente implementar os recursos de <function>epoll</function> e <function>inotify</function>.</para>
<para>Esperamos poder executar os programas mais importantes com perfeição em breve, por isso poderemos alternar para a emulação 2.6 por padrão e fazer do Fedora Core 6 o linux_base padrão porque o nosso atualmente usado Fedora Core 4 não é mais suportado.</para>
<para>O outro objetivo possível é compartilhar nosso código com o NetBSD e o DragonflyBSD. O NetBSD tem algum suporte para emulação 2.6, mas está longe de ser concluído e não foi realmente testado. O DragonflyBSD manifestou algum interesse em portar as melhorias do 2.6.</para>
<para>Geralmente, como o <trademark class="registered">Linux</trademark> se desenvolve, gostaríamos de acompanhar seu desenvolvimento, implementando a syscalls recém-adicionado. Splice vem em mente primeiro. Algumas syscalls já implementadas também são altamente danificadas, por exemplo <function>mremap</function> e outras. Alguns aprimoramentos de desempenho também podem ser feitos, um lock mais refinado e outros.</para>
</sect2>
<sect2 xml:id="team">
<title>Equipe</title>
<para>Eu colaborei neste projeto com (em ordem alfabética):</para>
<itemizedlist>
<listitem>
<para>John Baldwin <email>jhb@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Konstantin Belousov <email>kib@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Emmanuel Dreyfus</para>
</listitem>
<listitem>
<para>Scot Hetzel</para>
</listitem>
<listitem>
<para>Jung-uk Kim <email>jkim@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Alexander Leidinger <email>netchild@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Suleiman Souhlal <email>ssouhlal@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Li Xiao</para>
</listitem>
<listitem>
<para>David Xu <email>davidxu@FreeBSD.org</email></para>
</listitem>
</itemizedlist>
<para>Gostaria de agradecer a todas as pessoas por seus conselhos, revisões de código e apoio geral.</para>
</sect2>
</sect1>
<sect1 xml:id="literatures">
<title>Literaturas</title>
<orderedlist>
<listitem>
<para>Marshall Kirk McKusick - George V. Nevile-Neil. Design and Implementation of the FreeBSD operating system. Addison-Wesley, 2005.</para>
</listitem>
<listitem>
<para><uri xlink:href="https://tldp.org">https://tldp.org</uri></para>
</listitem>
<listitem>
<para><uri xlink:href="https://www.kernel.org">https://www.kernel.org</uri></para>
</listitem>
</orderedlist>
</sect1>
</article>