The translation is temporarily closed for contributions due to maintenance, please come back later.
English Portuguese (Brazil)
<trademark class="registered">Linux</trademark> passes arguments to syscalls via registers (that is why it is limited to 6 parameters on i386) while FreeBSD uses the stack. The <trademark class="registered">Linux</trademark> prepsyscall routine must copy parameters from registers to the stack. The order of the registers is: <varname>%ebx</varname>, <varname>%ecx</varname>, <varname>%edx</varname>, <varname>%esi</varname>, <varname>%edi</varname>, <varname>%ebp</varname>. The catch is that this is true for only <emphasis>most</emphasis> of the syscalls. Some (most notably <function>clone</function>) uses a different order but it is luckily easy to fix by inserting a dummy parameter in the <function>linux_clone</function> prototype. <trademark class="registered">Linux</trademark> passa argumentos via registradores de syscalls (isso porque ele é limitado a 6 parametros no i386) enquanto o FreeBSD usa uma pilha. A rotina prepsyscall do <trademark class="registered">Linux</trademark> deve copiar parametros dos registradores para a pilha. A ordem dos registradores é: <varname>%ebx</varname>, <varname>%ecx</varname>, <varname>%edx</varname>, <varname>%esi</varname>, <varname>%edi</varname>, <varname>%ebp</varname>. O fato é que isso é verdadeiro apenas para <emphasis>a maioria</emphasis> das syscalls. Algumas (mais provavelmente <function>clone</function>) usam uma ordem diferente, mas é demasiadamente facil de arrumar inserindo um parametro dummy no prototype <function>linux_clone</function>.
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.
The nature of emulation of different OSes (and also some other subsystems) led developers to invite a handler event mechanism. There are various places in the kernel, where a list of event handlers are called. Every subsystem can register an event handler and they are called accordingly. For example, when a process exits there is a handler called that possibly cleans up whatever the subsystem needs to be cleaned. A natureza da emulação de diferentes sistemas operacionais (e também alguns outros subsistemas) levou os desenvolvedores a invitar um mecanismo de evento manipulador. Existem vários locais no kernel, onde uma lista de manipuladores de eventos é chamada. Cada subsistema pode registrar um manipulador de eventos e eles são chamados de acordo com sua necessidade. Por exemplo, quando um processo é encerrado, há um manipulador chamado que possivelmente limpa o que o subsistema que ele precisa de limpeza.
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.
This masters thesis deals with updating the <trademark class="registered">Linux</trademark> emulation layer (the so called <firstterm>Linuxulator</firstterm>). The task was to update the layer to match the functionality of <trademark class="registered">Linux</trademark> 2.6. As a reference implementation, the <trademark class="registered">Linux</trademark> 2.6.16 kernel was chosen. The concept is loosely based on the NetBSD implementation. Most of the work was done in the summer of 2006 as a part of the Google Summer of Code students program. The focus was on bringing the <firstterm>NPTL</firstterm> (new <trademark class="registered">POSIX</trademark> thread library) support into the emulation layer, including <firstterm>TLS</firstterm> (thread local storage), <firstterm>futexes</firstterm> (fast user space mutexes), <firstterm>PID mangling</firstterm>, and some other minor things. Many small problems were identified and fixed in the process. My work was integrated into the main FreeBSD source repository and will be shipped in the upcoming 7.0R release. We, the emulation development team, are working on making the <trademark class="registered">Linux</trademark> 2.6 emulation the default emulation layer in FreeBSD. Essa tese master lida com a atualização da camada de emulação do <trademark class="registered">Linux</trademark> (o chamado <firstterm>Linuxulator</firstterm>). A tarefa foi atualizar a camada para casar com a funcionalidade do <trademark class="registered">Linux</trademark> 2.6. Como uma referencia a implementação, o kernel <trademark class="registered">Linux</trademark> 2.6.16 foi escolhido. O conceito é perdidamente baseado na implementação do NetBSD. Maior parte do trabalho foi feito no verão de 2006 como parte de um programa de estudante do Google Summer of Code. O foco foi trazer o suporte do <firstterm>NPTL</firstterm> (nova biblioteca de threads <trademark class="registered">POSIX</trademark>) pra dentro da camada de emulação, incluindo <firstterm>TLS</firstterm> (thread local storage), <firstterm>futexes</firstterm> (mutexes rapidos na camada de usuario), <firstterm>PID mangling</firstterm>, e algumas outras coisas menores. Muitos pequenos problemas foram identificados e corrigidos. Meu trabalho foi integrado dentro do repositório de principal do FreeBSD e vai ser ligado ao 7.0R release. Nós, o time de desenvolvimento de emulação estamos trabalhando na emulação do <trademark class="registered">Linux</trademark> 2.6 a camada de emulação padr
ão do FreeBSD.
This operation takes <varname>val</varname> threads queued on futex at <varname>uaddr</varname>, wakes them up, and takes <varname>val2</varname> next threads and requeues them on futex at <varname>uaddr2</varname>. Esta operação pega threads <varname>val</varname> enfileirados no futex em <varname>uaddr</varname>, acorda-os e pega as próximas threads <varname>val2</varname> e enfileira-os no futex em <varname>uaddr2</varname>.
We are able to run the most used applications like <package>www/linux-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. 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 de 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.
FreeBSD is a modern <trademark class="registered">UNIX</trademark>-based operating system with all the features of <trademark class="registered">UNIX</trademark>. Preemptive multitasking, multiuser facilities, TCP/IP networking, memory protection, symmetric multiprocessing support, virtual memory with merged VM and buffer cache, they are all there. One of the interesting and extremely useful features is the ability to emulate other <trademark class="registered">UNIX</trademark>-like operating systems. As of December 2006 and 7-CURRENT development, the following emulation functionalities are supported: O FreeBSD é um sistema operacional baseado no <trademark class="registered">UNIX</trademark> com todos os recursos do <trademark class="registered">UNIX</trademark>. Multitarefa preemptiva, necessidades de multiusuário, rede TCP/IP, proteção de memória, suporte a multiprocessamento simétrico, memória virtual com VM mesclada e cache de buffer, todos eles estão lá. Um dos recursos interessantes e extremamente úteis é a capacidade de emular outros sistemas operacionais <trademark class="registered">UNIX</trademark>-like. A partir de dezembro de 2006 e do desenvolvimento do 7-CURRENT, as seguintes funcionalidades de emulação são suportadas:
The PID is used to identify the FreeBSD process that attaches this structure. The <function>child_se_tid</function> and <function>child_clear_tid</function> are used for TID address copyout when a process exits and is created. The <varname>shared</varname> pointer points to a structure shared among threads. The <varname>pdeath_signal</varname> variable identifies the parent death signal and the <varname>threads</varname> pointer is used to link this structure to the list of threads. The <literal>linux_emuldata_shared</literal> structure looks like: O PID é usado para identificar o processo do FreeBSD que liga esta estrutura. <function> child_se_tid </function> e <function> child_clear_tid </function> são usadas para cópia do endereço TID quando um processo existe e é criado. O ponteiro <varname>shared</varname> aponta para uma estrutura compartilhada entre as threads. A variável <varname>pdeath_signal</varname> identifica o sinal de morte do processo pai e o ponteiro <varname>threads</varname> é usado para vincular essa estrutura à lista de threads. A estrutura <literal>linux_emuldata_shared</literal> se parece com:
Threads in computer science are entities within a process that can be scheduled independently from each other. The threads in the process share process wide data (file descriptors, etc.) but also have their own stack for their own data. Sometimes there is a need for process-wide data specific to a given thread. Imagine a name of the thread in execution or something like that. The traditional <trademark class="registered">UNIX</trademark> threading API, <application>pthreads</application> provides a way to do it via <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> where a thread can create a key to the thread local data and using <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> or <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> to manipulate those data. You can easily see that this is not the most comfortable way this could be accomplished. So various producers of C/C++ compilers introduced a better way. They defined a new modifier keyword thread that specifies that a variable is thread specific. A new method of accessing such variables was developed as well (at least on i386). The <application>pthreads</application> method tends to be implemented in userspace as a trivial lookup table. The performance of such a solution is not very good. So the new method uses (on i386) segment registers to address a segment, where TLS area is stored so the actual accessing of a thread variable is just appending the segment register to the address thus addressing via it. The segment registers are usually <varname>%gs</varname> and <varname>%fs</varname> acting like segment selectors. Every thread has its own area where the thread local data are stored and the segment must be loaded on every context switch. This method is very fast and used almost exclusively in the whole i386 <trademark class="registered">UNIX</trademark> world. Both FreeBSD and <trademark class="registered">Linux</trademark> implement this approach and it yields very good results. The only drawback is the need to reload the segment on every context switch which can slowdown context switches. FreeBSD tries to avoid this overhead by using only 1 segment descriptor for this while <trademark class="registered">Linux</trademark> uses 3. Interesting thing is that almost nothing uses more than 1 descriptor (only <application>Wine</application> seems to use 2) so <trademark class="registered">Linux</trademark> pays this unnecessary price for context switches. Threads na ciência da computação são entidades com um processo que podem ser agendados independentemente de qualquer outro. As threads nos processos compartilham amplos dados de processos (file descriptors, etc.) mas também tem sua prŕopria pilha para seus próprios dados. Algumas vezes é preciso para um processamento amplo de dados dado uma thread. Imagine um nome de uma thread algo assim. A tradicional API de threading do <trademark class="registered">UNIX</trademark>, <application>pthreads</application> prove um caminho para isso em <citerefentry><refentrytitle>pthread_key_create</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>pthread_setspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> onde a thread pode criar uma chave para os dados da thread local <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> ou <citerefentry><refentrytitle>pthread_getspecific</refentrytitle><manvolnum>3</manvolnum></citerefentry> para manipular esses dados. Você pode ver que esse não é o caminho mais confortavel que poderia ser usado. Então varios produtores de compiladores C/C++ introduziram um caminho melhor. Eles definiram uma nova chave modificadora de thread que especifica que a variavel é especifica de uma thread. Um novo método de acessar as variaveis foi desenvolvio como (ao menos no i386). O método <application>pthreads</application> tende a ser implementado no espaço de usuário como uma tabela de lookup trivial. A performance como uma solução não é muito boa. Então o novo método (no i386) registradores de segmentos para endereçar um segmento, onde a área do TLS é armazenada, então o atual acesso da variável de uma thread é apenas adicionada ao registrador de segmentos para o endereçamento via it. Os registradores de segmentos são usualmente <varname>%gs</varname> e <varname>%fs</varname> agindo como seletores de segmento. Toda thread tem sua própria área onde os dados da thread local são armazenados e o segmento deve ser carregado em toda troca de contexto. Esse método é muito rapido e usado em todo mundo em volta do <trademark class="registered">UNIX</trademark> i386. Ambos FreeBSD e <trademark class="registered">Linux</trademark> Implementam sua abordagem e seus resultados tem sido muito bons. Unico ponto negativo é ter que recarregar o segmento em toda troca de contexto que pode deixar o processo lento. FreeBSD tenta evitar essa sobrecarga usando apenas 1 descritor de segmento enquanto <trademark class="registered">Linux</trademark> usa 3. Interessante que isso quase nunca usa mais que 1 descritor (apenas o <application>Wine</application> parece usar 2) então o <trademark class="registered">Linux</trademark> paga esse preço desnecessário na troca de contexto.