Date: Wed, 11 Dec 2019 23:12:59 +0000 (UTC) From: "Danilo G. Baio" <dbaio@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r53680 - head/pt_BR.ISO8859-1/articles/linux-emulation Message-ID: <201912112312.xBBNCxcl079806@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dbaio (ports committer) Date: Wed Dec 11 23:12:58 2019 New Revision: 53680 URL: https://svnweb.freebsd.org/changeset/doc/53680 Log: pt_BR/articles/linux-emulation: Sync with en_US r53671 Approved by: ebrandi Obtained from: https://translate-dev.freebsd.org/ Differential Revision: https://reviews.freebsd.org/D22743 Modified: head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po Modified: head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml ============================================================================== --- head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml Wed Dec 11 23:10:01 2019 (r53679) +++ head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml Wed Dec 11 23:12:58 2019 (r53680) @@ -43,12 +43,12 @@ </sect1> <sect1 xml:id="inside"> - <title>Um olhar para dentro ...</title> + <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> + <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> @@ -61,7 +61,7 @@ <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>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> @@ -143,14 +143,14 @@ <para>Emulação de NetBSD do sistema operacional NetBSD</para> </listitem> <listitem> - <para>Suporte PECoff para executáveis PECoff do FreeBSD</para> + <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> + <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> + <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> @@ -166,9 +166,9 @@ <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>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 rit mo 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> + <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 rit mo 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"> @@ -216,7 +216,7 @@ <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 a qui:</para> + <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> @@ -342,7 +342,7 @@ <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>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> @@ -396,13 +396,13 @@ <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> + <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> + <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"> @@ -430,7 +430,7 @@ <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> + <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"> @@ -498,7 +498,7 @@ </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> + <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"> @@ -741,7 +741,7 @@ translate_traps(int signal, int trap_code) </sect1> <sect1 xml:id="mi"> - <title>Parte da amada de emulação -MI do <trademark class="registered">Linux </trademark> </title> + <title>Parte da camada 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> @@ -763,7 +763,7 @@ translate_traps(int signal, int trap_code) <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</refentryti tle><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> + <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><m anvolnum>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"> @@ -890,7 +890,7 @@ void * child_tidptr);</programlisting> <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 porq ue 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>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 sysca ll 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> @@ -950,7 +950,7 @@ pthread_mutex_unlock(&mutex);</programlisting> <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> + <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"> @@ -1111,7 +1111,7 @@ openat(stdio, bah\, flags, mode) /* returns error beca <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> + <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> @@ -1124,7 +1124,7 @@ openat(stdio, bah\, flags, mode) /* returns error beca <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>Nós podemos rodar os aplicativos mais usados como o <package>www/linux-firefox</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> Modified: head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po ============================================================================== --- head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po Wed Dec 11 23:10:01 2019 (r53679) +++ head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po Wed Dec 11 23:12:58 2019 (r53680) @@ -1,20 +1,20 @@ # $FreeBSD$ -# Danilo G. Baio <dbaio@FreeBSD.org>, 2018. #zanata -# Edson Brandi <ebrandi@FreeBSD.org>, 2018. #zanata -# Silvio Ap Silva <contato@kanazuchi.com>, 2018. #zanata +# Danilo G. Baio <dbaio@FreeBSD.org>, 2019. #zanata +# Edson Brandi <ebrandi@FreeBSD.org>, 2019. #zanata msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2018-09-06 00:46+0000\n" -"PO-Revision-Date: 2018-09-03 02:06+0000\n" -"Last-Translator: Edson Brandi <ebrandi@FreeBSD.org>\n" -"Language-Team: \n" +"POT-Creation-Date: 2019-12-09 21:30-0300\n" +"PO-Revision-Date: 2019-12-10 00:29+0000\n" +"Last-Translator: Danilo G. Baio <dbaio@FreeBSD.org>\n" +"Language-Team: Portuguese (Brazil) <https://weblate.eastus.cloudapp.azure." +"com/projects/freebsd-doc/articles_linux-emulation/pt_BR/>\n" "Language: pt_BR\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"X-Generator: Zanata 4.6.2\n" -"Plural-Forms: nplurals=2; plural=(n != 1)\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" +"X-Generator: Weblate 3.9.1\n" #. Put one translator per line, in the form NAME <EMAIL>, YEAR1, YEAR2 msgctxt "_" @@ -134,11 +134,11 @@ msgstr "" #. (itstool) path: info/releaseinfo #: article.translate.xml:54 article.translate.xml:56 msgid "" -"$FreeBSD: head/en_US.ISO8859-1/articles/linux-emulation/article.xml 51904 " -"2018-06-23 14:55:54Z bcr $" +"$FreeBSD: head/en_US.ISO8859-1/articles/linux-emulation/article.xml 53664 " +"2019-12-07 16:24:22Z carlavilla $" msgstr "" -"$FreeBSD: head/en_US.ISO8859-1/articles/linux-emulation/article.xml 51904 " -"2018-06-23 14:55:54Z bcr $" +"$FreeBSD: head/en_US.ISO8859-1/articles/linux-emulation/article.xml 53664 " +"2019-12-07 16:24:22Z carlavilla $" #. (itstool) path: abstract/para #: article.translate.xml:59 @@ -250,7 +250,7 @@ msgstr "" #. (itstool) path: sect1/title #: article.translate.xml:110 msgid "A look inside…" -msgstr "Um olhar para dentro ..." +msgstr "Um olhar para dentro…" #. (itstool) path: sect1/para #: article.translate.xml:112 @@ -274,7 +274,7 @@ msgstr "" #. (itstool) path: sect2/title #: article.translate.xml:120 msgid "What is <trademark class=\"registered\">UNIX</trademark>" -msgstr "O que é o <trademark class=\"registered\"> UNIX </trademark>?" +msgstr "O que é o <trademark class=\"registered\"> UNIX </trademark>" #. (itstool) path: sect2/para #: article.translate.xml:122 @@ -379,7 +379,7 @@ msgstr "" "<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 " +"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." @@ -616,7 +616,7 @@ msgstr "Emulação de NetBSD do sistema operacional Ne #. (itstool) path: listitem/para #: article.translate.xml:300 msgid "PECoff-support for PECoff FreeBSD executables" -msgstr "Suporte PECoff para executáveis PECoff do FreeBSD" +msgstr "Suporte PECoff para executáveis PECoff do FreeBSD" #. (itstool) path: listitem/para #: article.translate.xml:303 @@ -625,7 +625,7 @@ msgid "" "trademark>" msgstr "" "Emulação SVR4 do <trademark class=\"registered\">UNIX</trademark> System V " -"revisão 4 " +"revisão 4" #. (itstool) path: sect2/para #: article.translate.xml:307 @@ -636,7 +636,7 @@ msgid "" msgstr "" "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." +"funcionar corretamente nem ser utilizáveis nos dias de hoje." #. (itstool) path: sect3/para #: article.translate.xml:314 @@ -704,7 +704,7 @@ msgid "" msgstr "" "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." +"de syscall desejado com argumentos passados na pilha." #. (itstool) path: sect4/para #: article.translate.xml:350 @@ -741,7 +741,7 @@ msgstr "" "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 " +"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." @@ -1021,7 +1021,7 @@ msgstr "" "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 " +"espera que os parâmetros para o syscall sejam passados pelos registradores " "como mostrado aqui:" #. (itstool) path: listitem/para @@ -1451,7 +1451,7 @@ msgstr "" "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 " +"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." @@ -1700,7 +1700,7 @@ msgstr "" "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 " +"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 " @@ -1739,7 +1739,7 @@ msgid "" "<filename>sys/refcount.h</filename> for an overview of the existing API." msgstr "" "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 " +"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, " @@ -1814,7 +1814,7 @@ msgstr "" "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 " +"código ou, idealmente, não serem usados se não solicitados explicitamente " "( explicado posteriormente)." #. (itstool) path: sect4/title @@ -2028,7 +2028,7 @@ msgid "" "<citerefentry><refentrytitle>witness</refentrytitle><manvolnum>4</" "manvolnum></citerefentry>)." msgstr "" -"Geralmente, eles devem ser usados apenas em um contexto específico e, mesmo " +"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</" @@ -2982,8 +2982,8 @@ msgstr "" msgid "" "<trademark class=\"registered\">Linux</trademark> emulation layer -MI part" msgstr "" -"Parte da amada de emulação -MI do <trademark class=\"registered\">Linux </" -"trademark> " +"Parte da camada de emulação -MI do <trademark class=\"registered\">Linux</" +"trademark>" #. (itstool) path: sect1/para #: article.translate.xml:1545 @@ -3122,7 +3122,7 @@ msgstr "" "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 " +"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</" @@ -3867,13 +3867,13 @@ msgstr "" "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 " +"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 " +"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 " @@ -4052,7 +4052,7 @@ msgid "" "<varname>val</varname> first futexes queued on this futex." msgstr "" "Esta operação tem um futex em <varname>uaddr</varname> e acorda os primeiros " -"futexes <varname>val</varname> enfileirados neste futex. " +"futexes <varname>val</varname> enfileirados neste futex." #. (itstool) path: sect4/title #: article.translate.xml:2090 @@ -4659,7 +4659,7 @@ msgstr "" "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 " +"macros LMSG e ARGS. Essas são usadas para alterar uma string imprimível para " "mensagens uniformes de depuração." #. (itstool) path: sect1/title @@ -4706,29 +4706,27 @@ msgstr "" #: article.translate.xml:2455 msgid "" "We are able to run the most used applications like <package>www/linux-" -"firefox</package>, <package>www/linux-opera</package>, <package>net-im/" -"skype</package> and some games from the Ports Collection. Some of the " -"programs exhibit bad behavior under 2.6 emulation but this is currently " -"under investigation and hopefully will be fixed soon. The only big " -"application that is known not to work is the <trademark class=\"registered" -"\">Linux</trademark> <trademark>Java</trademark> Development Kit and this is " -"because of the requirement of <function>epoll</function> facility which is " -"not directly related to the <trademark class=\"registered\">Linux</" -"trademark> kernel 2.6." +"firefox</package>, <package>net-im/skype</package> and some games from the " +"Ports Collection. Some of the programs exhibit bad behavior under 2.6 " +"emulation but this is currently under investigation and hopefully will be " +"fixed soon. The only big application that is known not to work is the " +"<trademark class=\"registered\">Linux</trademark> <trademark>Java</" +"trademark> Development Kit and this is because of the requirement of " +"<function>epoll</function> facility which is not directly related to the " +"<trademark class=\"registered\">Linux</trademark> kernel 2.6." msgstr "" -"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." +"Nós podemos rodar os aplicativos mais usados como o <package>www/linux-" +"firefox</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." #. (itstool) path: sect2/para -#: article.translate.xml:2467 +#: article.translate.xml:2466 msgid "" "We hope to enable 2.6.16 emulation by default some time after FreeBSD 7.0 is " "released at least to expose the 2.6 emulation parts for some wider testing. " @@ -4741,12 +4739,12 @@ msgstr "" "linux_base, que é o plano final." #. (itstool) path: sect2/title -#: article.translate.xml:2475 +#: article.translate.xml:2474 msgid "Future work" msgstr "Trabalho futuro" #. (itstool) path: sect2/para -#: article.translate.xml:2477 +#: article.translate.xml:2476 msgid "" "Future work should focus on fixing the remaining issues with futexes, " "implement the rest of the *at family of syscalls, fix the signal delivery " @@ -4759,7 +4757,7 @@ msgstr "" "function> e <function>inotify</function>." #. (itstool) path: sect2/para -#: article.translate.xml:2483 +#: article.translate.xml:2482 msgid "" "We hope to be able to run the most important programs flawlessly soon, so we " "will be able to switch to the 2.6 emulation by default and make the " @@ -4772,7 +4770,7 @@ msgstr "" "Core 4 não é mais suportado." #. (itstool) path: sect2/para -#: article.translate.xml:2489 +#: article.translate.xml:2488 msgid "" "The other possible goal is to share our code with NetBSD and DragonflyBSD. " "NetBSD has some support for 2.6 emulation but its far from finished and not " @@ -4785,7 +4783,7 @@ msgstr "" "algum interesse em portar as melhorias do 2.6." #. (itstool) path: sect2/para -#: article.translate.xml:2495 +#: article.translate.xml:2494 msgid "" "Generally, as <trademark class=\"registered\">Linux</trademark> develops we " "would like to keep up with their development, implementing newly added " @@ -4802,62 +4800,62 @@ msgstr "" "também podem ser feitos, um lock mais refinado e outros." #. (itstool) path: sect2/title -#: article.translate.xml:2505 +#: article.translate.xml:2504 msgid "Team" msgstr "Equipe" #. (itstool) path: sect2/para -#: article.translate.xml:2507 +#: article.translate.xml:2506 msgid "I cooperated on this project with (in alphabetical order):" msgstr "Eu colaborei neste projeto com (em ordem alfabética):" #. (itstool) path: listitem/para -#: article.translate.xml:2512 +#: article.translate.xml:2511 msgid "John Baldwin <email>jhb@FreeBSD.org</email>" msgstr "John Baldwin <email>jhb@FreeBSD.org</email>" #. (itstool) path: listitem/para -#: article.translate.xml:2515 +#: article.translate.xml:2514 msgid "Konstantin Belousov <email>kib@FreeBSD.org</email>" msgstr "Konstantin Belousov <email>kib@FreeBSD.org</email>" #. (itstool) path: listitem/para -#: article.translate.xml:2518 +#: article.translate.xml:2517 msgid "Emmanuel Dreyfus" msgstr "Emmanuel Dreyfus" #. (itstool) path: listitem/para -#: article.translate.xml:2521 +#: article.translate.xml:2520 msgid "Scot Hetzel" msgstr "Scot Hetzel" #. (itstool) path: listitem/para -#: article.translate.xml:2524 +#: article.translate.xml:2523 msgid "Jung-uk Kim <email>jkim@FreeBSD.org</email>" msgstr "Jung-uk Kim <email>jkim@FreeBSD.org</email>" #. (itstool) path: listitem/para -#: article.translate.xml:2527 +#: article.translate.xml:2526 msgid "Alexander Leidinger <email>netchild@FreeBSD.org</email>" msgstr "Alexander Leidinger <email>netchild@FreeBSD.org</email>" #. (itstool) path: listitem/para -#: article.translate.xml:2530 +#: article.translate.xml:2529 msgid "Suleiman Souhlal <email>ssouhlal@FreeBSD.org</email>" msgstr "Suleiman Souhlal <email>ssouhlal@FreeBSD.org</email>" #. (itstool) path: listitem/para -#: article.translate.xml:2533 +#: article.translate.xml:2532 msgid "Li Xiao" msgstr "Li Xiao" #. (itstool) path: listitem/para -#: article.translate.xml:2536 +#: article.translate.xml:2535 msgid "David Xu <email>davidxu@FreeBSD.org</email>" msgstr "David Xu <email>davidxu@FreeBSD.org</email>" #. (itstool) path: sect2/para -#: article.translate.xml:2540 +#: article.translate.xml:2539 msgid "" "I would like to thank all those people for their advice, code reviews and " "general support." @@ -4866,12 +4864,12 @@ msgstr "" "código e apoio geral." #. (itstool) path: sect1/title -#: article.translate.xml:2546 +#: article.translate.xml:2545 msgid "Literatures" msgstr "Literaturas" #. (itstool) path: listitem/para -#: article.translate.xml:2550 +#: article.translate.xml:2549 msgid "" "Marshall Kirk McKusick - George V. Nevile-Neil. Design and Implementation of " "the FreeBSD operating system. Addison-Wesley, 2005." @@ -4880,12 +4878,12 @@ msgstr "" "the FreeBSD operating system. Addison-Wesley, 2005." #. (itstool) path: listitem/para -#: article.translate.xml:2555 +#: article.translate.xml:2554 msgid "<uri xlink:href=\"https://tldp.org\">https://tldp.org</uri>" msgstr "<uri xlink:href=\"https://tldp.org\">https://tldp.org</uri>" #. (itstool) path: listitem/para -#: article.translate.xml:2558 +#: article.translate.xml:2557 msgid "<uri xlink:href=\"https://www.kernel.org\">https://www.kernel.org</uri>" msgstr "" "<uri xlink:href=\"https://www.kernel.org\">https://www.kernel.org</uri>"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201912112312.xBBNCxcl079806>