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

Translation

(itstool) path: sect2/para
English
<trademark class="registered">Linux</trademark> emulation in FreeBSD implements the <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> facility in <filename>linux_ptrace.c</filename>. The routines for converting registers between <trademark class="registered">Linux</trademark> and FreeBSD and the actual <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall emulation syscall. The syscall is a long switch block that implements its counterpart in FreeBSD for every <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> command. The <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> commands are mostly equal between <trademark class="registered">Linux</trademark> and FreeBSD so usually just a small modification is needed. For example, <literal>PT_GETREGS</literal> in <trademark class="registered">Linux</trademark> operates on direct data while FreeBSD uses a pointer to the data so after performing a (native) <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall, a copyout must be done to preserve <trademark class="registered">Linux</trademark> semantics.
Context English Portuguese (Brazil) State
And finally, <filename>linux_sysent.c</filename> contains structure describing the system entry table, used to actually dispatch a syscall, e.g.: 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:
{ 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 */
{ 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 */
As you can see <function>linux_fork</function> is implemented in Linuxulator itself so the definition is of <literal>STD</literal> type and has no argument, which is exhibited by the dummy argument structure. On the other hand <function>close</function> is just an alias for real FreeBSD <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> so it has no linux arguments structure associated and in the system entry table it is not prefixed with linux as it calls the real <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> in the kernel. 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.
Dummy syscalls Dummy syscalls
The <trademark class="registered">Linux</trademark> emulation layer is not complete, as some syscalls are not implemented properly and some are not implemented at all. The emulation layer employs a facility to mark unimplemented syscalls with the <literal>DUMMY</literal> macro. These dummy definitions reside in <filename>linux_dummy.c</filename> in a form of <literal>DUMMY(syscall);</literal>, which is then translated to various syscall auxiliary files and the implementation consists of printing a message saying that this syscall is not implemented. The <literal>UNIMPL</literal> prototype is not used because we want to be able to identify the name of the syscall that was called in order to know what syscalls are more important to implement. 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.
Signal handling Manuseio de signals
Signal handling is done generally in the FreeBSD kernel for all binary compatibilities with a call to a compat-dependent layer. <trademark class="registered">Linux</trademark> compatibility layer defines <function>linux_sendsig</function> routine for this purpose. 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.
<trademark class="registered">Linux</trademark> sendsig <trademark class="registered">Linux</trademark> sendsig
This routine first checks whether the signal has been installed with a <literal>SA_SIGINFO</literal> in which case it calls <function>linux_rt_sendsig</function> routine instead. Furthermore, it allocates (or reuses an already existing) signal handle context, then it builds a list of arguments for the signal handler. It translates the signal number based on the signal translation table, assigns a handler, translates sigset. Then it saves context for the <function>sigreturn</function> routine (various registers, translated trap number and signal mask). Finally, it copies out the signal context to the userspace and prepares context for the actual signal handler to run. 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.
linux_rt_sendsig linux_rt_sendsig
This routine is similar to <function>linux_sendsig</function> just the signal context preparation is different. It adds <literal>siginfo</literal>, <literal>ucontext</literal>, and some <trademark class="registered">POSIX</trademark> parts. It might be worth considering whether those two functions could not be merged with a benefit of less code duplication and possibly even faster execution. 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.
linux_sigreturn linux_sigreturn
This syscall is used for return from the signal handler. It does some security checks and restores the original process context. It also unmasks the signal in process signal mask. 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.
Ptrace Ptrace
Many <trademark class="registered">UNIX</trademark> derivates implement the <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall in order to allow various tracking and debugging features. This facility enables the tracing process to obtain various information about the traced process, like register dumps, any memory from the process address space, etc. and also to trace the process like in stepping an instruction or between system entries (syscalls and traps). <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> also lets you set various information in the traced process (registers etc.). <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> is a <trademark class="registered">UNIX</trademark>-wide standard implemented in most <trademark class="registered">UNIX</trademark>es around the world. 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.
<trademark class="registered">Linux</trademark> emulation in FreeBSD implements the <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> facility in <filename>linux_ptrace.c</filename>. The routines for converting registers between <trademark class="registered">Linux</trademark> and FreeBSD and the actual <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall emulation syscall. The syscall is a long switch block that implements its counterpart in FreeBSD for every <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> command. The <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> commands are mostly equal between <trademark class="registered">Linux</trademark> and FreeBSD so usually just a small modification is needed. For example, <literal>PT_GETREGS</literal> in <trademark class="registered">Linux</trademark> operates on direct data while FreeBSD uses a pointer to the data so after performing a (native) <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall, a copyout must be done to preserve <trademark class="registered">Linux</trademark> semantics. 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>.
The <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> implementation in Linuxulator has some known weaknesses. There have been panics seen when using <command>strace</command> (which is a <citerefentry><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry> consumer) in the Linuxulator environment. Also <literal>PT_SYSCALL</literal> is not implemented. 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.
Whenever a <trademark class="registered">Linux</trademark> process running in the emulation layer traps the trap itself is handled transparently with the only exception of the trap translation. <trademark class="registered">Linux</trademark> and FreeBSD differs in opinion on what a trap is so this is dealt with here. The code is actually very short: 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:
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;
}
}
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;
}
}
Stack fixup Correção de pilha
The RTLD run-time link-editor expects so called AUX tags on stack during an <function>execve</function> so a fixup must be done to ensure this. Of course, every RTLD system is different so the emulation layer must provide its own stack fixup routine to do this. So does Linuxulator. The <function>elf_linux_fixup</function> simply copies out AUX tags to the stack and adjusts the stack of the user space process to point right after those tags. So RTLD works in a smart way. 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.
A.OUT support Suporte para A.OUT
The <trademark class="registered">Linux</trademark> emulation layer on i386 also supports <trademark class="registered">Linux</trademark> A.OUT binaries. Pretty much everything described in the previous sections must be implemented for A.OUT support (beside traps translation and signals sending). The support for A.OUT binaries is no longer maintained, especially the 2.6 emulation does not work with it but this does not cause any problem, as the linux-base in ports probably do not support A.OUT binaries at all. This support will probably be removed in future. Most of the stuff necessary for loading <trademark class="registered">Linux</trademark> A.OUT binaries is in <filename>imgact_linux.c</filename> file. 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>.
<trademark class="registered">Linux</trademark> emulation layer -MI part Parte da camada de emulação -MI do <trademark class="registered">Linux</trademark>
This section talks about machine independent part of the Linuxulator. It covers the emulation infrastructure needed for <trademark class="registered">Linux</trademark> 2.6 emulation, the thread local storage (TLS) implementation (on i386) and futexes. Then we talk briefly about some syscalls. 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.
Description of NPTL Descrição do NPTL
One of the major areas of progress in development of <trademark class="registered">Linux</trademark> 2.6 was threading. Prior to 2.6, the <trademark class="registered">Linux</trademark> threading support was implemented in the <application>linuxthreads</application> library. The library was a partial implementation of <trademark class="registered">POSIX</trademark> threading. The threading was implemented using separate processes for each thread using the <function>clone</function> syscall to let them share the address space (and other things). The main weaknesses of this approach was that every thread had a different PID, signal handling was broken (from the pthreads perspective), etc. Also the performance was not very good (use of <literal>SIGUSR</literal> signals for threads synchronization, kernel resource consumption, etc.) so to overcome these problems a new threading system was developed and named NPTL. 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.
The NPTL library focused on two things but a third thing came along so it is usually considered a part of NPTL. Those two things were embedding of threads into a process structure and futexes. The additional third thing was TLS, which is not directly required by NPTL but the whole NPTL userland library depends on it. Those improvements yielded in much improved performance and standards conformance. NPTL is a standard threading library in <trademark class="registered">Linux</trademark> systems these days. 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.
The FreeBSD Linuxulator implementation approaches the NPTL in three main areas. The TLS, futexes and PID mangling, which is meant to simulate the <trademark class="registered">Linux</trademark> threads. Further sections describe each of these areas. 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.
<trademark class="registered">Linux</trademark> 2.6 emulation infrastructure Infra-estrutura de emulação do <trademark class="registered">Linux</trademark> 2.6
These sections deal with the way <trademark class="registered">Linux</trademark> threads are managed and how we simulate that in FreeBSD. 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.

Loading…

No matching activity found.

Browse all component changes

Things to check

Consecutive duplicated words

Text contains the same word twice in a row: syscall

Reset

Glossary

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

Source information

Source string comment
(itstool) path: sect2/para
Source string location
article.translate.xml:1461
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/linux-emulation.po, string 230