Index: head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml
===================================================================
--- head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml
+++ head/pt_BR.ISO8859-1/articles/linux-emulation/article.xml
@@ -43,12 +43,12 @@
- Um olhar para dentro ...
+ Um olhar para dentro…
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 UNIX, como o que é um PID, o que é uma thread, etc. Na terceira subseção, falamos sobre como UNIX em emuladores UNIX pode ser feita em geral.
- O que é o UNIX ?
+ O que é o UNIX
UNIX é 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 UNIX logo se bifurcou em duas formas principais: as famílias BSDs e System III/V. Eles se influenciaram mutuamente ao desenvolver um padrão UNIX 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. UNIX 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 UNIX. Hoje em dia os mais influentes são Linux, Solaris e possivelmente (até certo ponto) FreeBSD. Existem sistemas UNIX 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 UNIX.
@@ -61,7 +61,7 @@
Comunicação entre o kernel e o processo de espaço do usuário
- A API comum do UNIX 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 SYSENTER/SYSCALL para ia32). Syscalls são definidos por um número. Por exemplo, no FreeBSD, a syscall número 85 é a syscall swapon2 e a syscall número 132 é a syscall mkfifo2. 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.
+ A API comum do UNIX 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 SYSENTER/SYSCALL para ia32). Syscalls são definidos por um número. Por exemplo, no FreeBSD, a syscall número 85 é a syscall swapon2 e a syscall número 132 é a syscall mkfifo2. 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.
Outra maneira possível de se comunicar é usando uma trap. 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 signal (divisão por zero).
@@ -143,14 +143,14 @@
Emulação de NetBSD do sistema operacional NetBSD
- Suporte PECoff para executáveis PECoff do FreeBSD
+ Suporte PECoff para executáveis PECoff do FreeBSD
- Emulação SVR4 do UNIX System V revisão 4
+ Emulação SVR4 do UNIX System V revisão 4
- Emulações ativamente desenvolvidas são a camada Linux e várias camadas FreeBSD-on-FreeBSD. Outros não devem funcionar corretamente nem ser utilizáveis nos dias de hoje.
+ Emulações ativamente desenvolvidas são a camada Linux e várias camadas FreeBSD-on-FreeBSD. Outros não devem funcionar corretamente nem ser utilizáveis nos dias de hoje.
Detalhes técnicos
@@ -166,9 +166,9 @@
Syscalls
- Syscalls no FreeBSD são emitidos executando a interrupção 0x80 com o registrador %eax definido para um número de syscall desejado com argumentos passados na pilha.
+ Syscalls no FreeBSD são emitidos executando a interrupção 0x80 com o registrador %eax definido para um número de syscall desejado com argumentos passados na pilha.
- Quando um processo emite uma interrupção 0x80, a syscall manipuladora de trap int0x80 é proclamada (definida em sys/i386/i386/exception.s), que prepara argumentos (ou seja, copia-os para a pilha) para uma chamada para uma função C syscall2 (definida em sys/i386/i386/trap.c), que processa o trapframe passado. O processamento consiste em preparar a syscall (dependendo da entrada sysvec), 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 ERESTART e EJUSTRETURN). Finalmente, um userret() é 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 struct thread *td , struct syscall args* onde o segundo parâmetro é um ponteiro para o copiado na estrutura de parâmetros.
+ Quando um processo emite uma interrupção 0x80, a syscall manipuladora de trap int0x80 é proclamada (definida em sys/i386/i386/exception.s), que prepara argumentos (ou seja, copia-os para a pilha) para uma chamada para uma função C syscall2 (definida em sys/i386/i386/trap.c), que processa o trapframe passado. O processamento consiste em preparar a syscall (dependendo da entrada sysvec), 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 ERESTART e EJUSTRETURN). Finalmente, um userret() é 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 struct thread *td , struct syscall args* onde o segundo parâmetro é um ponteiro para o copiado na estrutura de parâmetros.
@@ -216,7 +216,7 @@
Syscalls
- Syscalls em Linux são executados (no espaço de usuário) usando macros syscallX 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 % eax com um número da syscall e executa a interrupção 0x80. Depois disso, um retorn da syscall é chamado, o que traduz valores de retorno negativos para valores errno positivos e define res para -1 em caso de erro. Sempre que a interrupção 0x80 é 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 Linux espera que os parâmetros para o syscall sejam passados pelos registradores como mostrado aqui:
+ Syscalls em Linux são executados (no espaço de usuário) usando macros syscallX 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 % eax com um número da syscall e executa a interrupção 0x80. Depois disso, um retorn da syscall é chamado, o que traduz valores de retorno negativos para valores errno positivos e define res para -1 em caso de erro. Sempre que a interrupção 0x80 é 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 Linux espera que os parâmetros para o syscall sejam passados pelos registradores como mostrado aqui:
@@ -342,7 +342,7 @@
Existem algumas syscalls que afetam o estado interno, mas isso pode ser resolvido fornecendo algumas estruturas que mantêm o estado extra.
- 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.
+ 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.
O mesmo acontece com a API do UNIX. A maioria dos programas pode viver com um conjunto muito limitado de syscalls funcionando. Essas syscalls tendem a ser as mais antigas (read2/write2,fork2family, signal3handling, exit3, socket2 API), portanto, é fácil emular porque sua semântica é compartilhada entre todos os UNIX, que existem hoje.
@@ -396,13 +396,13 @@
Operações atômicas e barreiras de memória
- 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 .long.), 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 atomic9. É 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).
+ 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 .long.), 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 atomic9. É 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).
Refcounts
- 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 sys/refcount.h para uma visão geral da API existente.
+ 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 sys/refcount.h para uma visão geral da API existente.
@@ -430,7 +430,7 @@
Spinning locks
- 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).
+ 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).
@@ -498,7 +498,7 @@
- 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 witness4).
+ 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 witness4).
@@ -741,7 +741,7 @@
- Parte da amada de emulação -MI do Linux
+ Parte da camada de emulação -MI do Linux
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 Linux 2.6, a implementação do TLS (thread local storage) (no i386) e os futexes. Então falamos brevemente sobre algumas syscalls.
@@ -763,7 +763,7 @@
Determinação de tempo de execução de emulação 2.6
- A camada de emulação do Linux no FreeBSD suporta a configuração de tempo de execução da versão emulada. Isso é feito via sysctl8, a saber compat.linux.osrelease. A configuração dessa sysctl8 afeta o comportamento de tempo de execução da camada de emulação. Quando definido como 2.6.x, ele configura o valor de linux_use_linux26 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 Linux. A sysctl8 não deve ser alterada ao executar qualquer binário do Linux, pois pode causar danos .
+ A camada de emulação do Linux no FreeBSD suporta a configuração de tempo de execução da versão emulada. Isso é feito via sysctl8, a saber compat.linux.osrelease. A configuração dessa sysctl8 afeta o comportamento de tempo de execução da camada de emulação. Quando definido como 2.6.x, ele configura o valor de linux_use_linux26 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 Linux. A sysctl8 não deve ser alterada ao executar qualquer binário do Linux, pois pode causar danos .
@@ -890,7 +890,7 @@
Introdução à sincronização
- Threads precisam de algum tipo de sincronização e POSIX 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 POSIX 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 ZFS (um usuário sx pesado), isso é algo in-kernel, mas mostra claramente quão importante é o desempenho das primitivas de sincronização. .
+ Threads precisam de algum tipo de sincronização e POSIX 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 POSIX 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 ZFS (um usuário sx pesado), isso é algo in-kernel, mas mostra claramente quão importante é o desempenho das primitivas de sincronização. .
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.
@@ -950,7 +950,7 @@
FUTEX_WAKE
- Esta operação tem um futex em uaddr e acorda os primeiros futexes val enfileirados neste futex.
+ Esta operação tem um futex em uaddr e acorda os primeiros futexes val enfileirados neste futex.
@@ -1111,7 +1111,7 @@
Depuração
- 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.
+ 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.
@@ -1124,7 +1124,7 @@
Em abril de 2007, a camada de emulação do Linux é capaz de emular o kernel Linux 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 epoll e inotify e provavelmente alguns bugs que ainda não descobrimos. Apesar disso, somos capazes de executar basicamente todos os programas Linux 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.
- Nós podemos rodar os aplicativos mais usados como o www/linux-firefox, www/linux-opera, net-im/skype 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 Java Development Kit do Linux e isto é devido ao requisito de epoll habilidade que não está diretamente relacionada ao kernel do Linux 2.6.
+ Nós podemos rodar os aplicativos mais usados como o www/linux-firefox, net-im/skype 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 Java Development Kit do Linux e isto é devido ao requisito de epoll habilidade que não está diretamente relacionada ao kernel do Linux 2.6.
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.
Index: head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po
===================================================================
--- head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po
+++ head/pt_BR.ISO8859-1/articles/linux-emulation/pt_BR.po
@@ -1,20 +1,20 @@
# $FreeBSD$
-# Danilo G. Baio , 2018. #zanata
-# Edson Brandi , 2018. #zanata
-# Silvio Ap Silva , 2018. #zanata
+# Danilo G. Baio , 2019. #zanata
+# Edson Brandi , 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 \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 \n"
+"Language-Team: Portuguese (Brazil) \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 , YEAR1, YEAR2
msgctxt "_"
@@ -134,11 +134,11 @@
#. (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 @@
#. (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 @@
#. (itstool) path: sect2/title
#: article.translate.xml:120
msgid "What is UNIX"
-msgstr "O que é o UNIX ?"
+msgstr "O que é o UNIX "
#. (itstool) path: sect2/para
#: article.translate.xml:122
@@ -379,7 +379,7 @@
"swapon2"
"citerefentry> e a syscall número 132 é a syscall "
"mkfifo2"
-"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 @@
#. (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 @@
"trademark>"
msgstr ""
"Emulação SVR4 do UNIX System V "
-"revisão 4 "
+"revisão 4"
#. (itstool) path: sect2/para
#: article.translate.xml:307
@@ -636,7 +636,7 @@
msgstr ""
"Emulações ativamente desenvolvidas são a camada Linux 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 @@
msgstr ""
"Syscalls no FreeBSD são emitidos executando a interrupção 0x80 "
"literal> com o registrador %eax 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 @@
"retorno (casos especiais para erros ERESTART e "
"EJUSTRETURN). Finalmente, um userret() "
"é 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 "
"struct thread *td , struct syscall args*"
"literal> onde o segundo parâmetro é um ponteiro para o copiado na estrutura "
"de parâmetros."
@@ -1021,7 +1021,7 @@
"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 Linux "
-"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 @@
"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 @@
"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 .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 @@
"sys/refcount.h 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 @@
"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 @@
"witness4"
"manvolnum>)."
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 witness"
@@ -2982,8 +2982,8 @@
msgid ""
"Linux emulation layer -MI part"
msgstr ""
-"Parte da amada de emulação -MI do Linux "
-"trademark> "
+"Parte da camada de emulação -MI do Linux"
+"trademark>"
#. (itstool) path: sect1/para
#: article.translate.xml:1545
@@ -3122,7 +3122,7 @@
"de tempo de execução da camada de emulação. Quando definido como 2.6.x, ele "
"configura o valor de linux_use_linux26 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 Linux. A sysctl"
@@ -3867,13 +3867,13 @@
"Threads precisam de algum tipo de sincronização e POSIX 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 POSIX 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 @@
"val first futexes queued on this futex."
msgstr ""
"Esta operação tem um futex em uaddr e acorda os primeiros "
-"futexes val enfileirados neste futex. "
+"futexes val enfileirados neste futex."
#. (itstool) path: sect4/title
#: article.translate.xml:2090
@@ -4659,7 +4659,7 @@
"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 @@
#: article.translate.xml:2455
msgid ""
"We are able to run the most used applications like www/linux-"
-"firefox, www/linux-opera, net-im/"
-"skype 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 Linux Java Development Kit and this is "
-"because of the requirement of epoll facility which is "
-"not directly related to the Linux"
-"trademark> kernel 2.6."
+"firefox, net-im/skype 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 "
+"Linux Java"
+"trademark> Development Kit and this is because of the requirement of "
+"epoll facility which is not directly related to the "
+"Linux kernel 2.6."
msgstr ""
-"Nós podemos rodar os aplicativos mais usados como o www/linux-"
-"firefox, www/linux-opera, net-im/"
-"skype 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 Java Development Kit "
-"do Linux e isto é devido ao "
-"requisito de epoll habilidade que não está diretamente "
-"relacionada ao kernel do Linux "
-"2.6."
+"Nós podemos rodar os aplicativos mais usados como o www/linux-"
+"firefox, net-im/skype 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 "
+"Java Development Kit do Linux e isto é devido ao requisito de epoll"
+"function> habilidade que não está diretamente relacionada ao kernel do "
+"Linux 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 @@
"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 @@
"function> e inotify."
#. (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 @@
"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 @@
"algum interesse em portar as melhorias do 2.6."
#. (itstool) path: sect2/para
-#: article.translate.xml:2495
+#: article.translate.xml:2494
msgid ""
"Generally, as Linux develops we "
"would like to keep up with their development, implementing newly added "
@@ -4802,62 +4800,62 @@
"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 jhb@FreeBSD.org"
msgstr "John Baldwin jhb@FreeBSD.org"
#. (itstool) path: listitem/para
-#: article.translate.xml:2515
+#: article.translate.xml:2514
msgid "Konstantin Belousov kib@FreeBSD.org"
msgstr "Konstantin Belousov kib@FreeBSD.org"
#. (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 jkim@FreeBSD.org"
msgstr "Jung-uk Kim jkim@FreeBSD.org"
#. (itstool) path: listitem/para
-#: article.translate.xml:2527
+#: article.translate.xml:2526
msgid "Alexander Leidinger netchild@FreeBSD.org"
msgstr "Alexander Leidinger netchild@FreeBSD.org"
#. (itstool) path: listitem/para
-#: article.translate.xml:2530
+#: article.translate.xml:2529
msgid "Suleiman Souhlal ssouhlal@FreeBSD.org"
msgstr "Suleiman Souhlal ssouhlal@FreeBSD.org"
#. (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 davidxu@FreeBSD.org"
msgstr "David Xu davidxu@FreeBSD.org"
#. (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 @@
"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 @@
"the FreeBSD operating system. Addison-Wesley, 2005."
#. (itstool) path: listitem/para
-#: article.translate.xml:2555
+#: article.translate.xml:2554
msgid "https://tldp.org"
msgstr "https://tldp.org"
#. (itstool) path: listitem/para
-#: article.translate.xml:2558
+#: article.translate.xml:2557
msgid "https://www.kernel.org"
msgstr ""
"https://www.kernel.org"