Translation Information

Project website wiki.freebsd.org/DocTranslationOnWeblate
Mailing list for translators freebsd-translators@freebsd.org
Instructions for translators

https://wiki.freebsd.org/DocTranslationOnWeblate

Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Only chosen users can contribute.
  • The translation uses bilingual files.
Translation license BSD-2-Clause-FreeBSD
Filemask articles/*/linux-emulation.po
Translation file articles/pt_BR/linux-emulation.po
Resource update 5 months ago
Resource update 6 months ago
Committed changes 7 months ago
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 Fedora Core 6 the default linux_base because our currently used Fedora Core 4 is not supported any more.
Esperamos poder executar os programas mais importantes com perfeição em breve, por isso poderemos alternar para a emulação 2.6 por padrão e fazer do Fedora Core 6 o linux_base padrão porque o nosso atualmente usado Fedora Core 4 não é mais suportado.
7 months ago
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. Once this is done we can switch to Fedora Core 6 linux_base, which is the ultimate plan.
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.
7 months ago
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 cColeção dos pe 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.
7 months ago
As of April 2007 the <trademark class="registered">Linux</trademark> emulation layer is capable of emulating the <trademark class="registered">Linux</trademark> 2.6.16 kernel quite well. The remaining problems concern futexes, unfinished *at family of syscalls, problematic signals delivery, missing <function>epoll</function> and <function>inotify</function> and probably some bugs we have not discovered yet. Despite this we are capable of running basically all the <trademark class="registered">Linux</trademark> programs included in FreeBSD Ports Collection with Fedora Core 4 at 2.6.16 and there are some rudimentary reports of success with Fedora Core 6 at 2.6.16. The Fedora Core 6 linux_base was recently committed enabling some further testing of the emulation layer and giving us some more hints where we should put our effort in implementing missing stuff.
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.
7 months ago
The ioctl interface is quite fragile due to its generality. We have to bear in mind that devices differ between <trademark class="registered">Linux</trademark> and FreeBSD so some care must be applied to do ioctl emulation work right. The ioctl handling is implemented in <filename>linux_ioctl.c</filename>, where <function>linux_ioctl</function> function is defined. This function simply iterates over sets of ioctl handlers to find a handler that implements a given command. The ioctl syscall has three parameters, the file descriptor, command and an argument. The command is a 16-bit number, which in theory is divided into high 8 bits determining class of the ioctl command and low 8 bits, which are the actual command within the given set. The emulation takes advantage of this division. We implement handlers for each set, like <function>sound_handler</function> or <function>disk_handler</function>. Each handler has a maximum command and a minimum command defined, which is used for determining what handler is used. There are slight problems with this approach because <trademark class="registered">Linux</trademark> does not use the set division consistently so sometimes ioctls for a different set are inside a set they should not belong to (SCSI generic ioctls inside cdrom set, etc.). FreeBSD currently does not implement many <trademark class="registered">Linux</trademark> ioctls (compared to NetBSD, for example) but the plan is to port those from NetBSD. The trend is to use <trademark class="registered">Linux</trademark> ioctls even in the native FreeBSD drivers because of the easy porting of applications.
A interface ioctl é bastante frágil devido à sua generalidade. Nós temos que ter em mente que os dispositivos diferem entre <trademark class="registered">Linux</trademark> e FreeBSD, então alguns cuidados devem ser aplicados para fazer o trabalho de emulação de ioctl corretamente. O manuseio ioctl é implementado em <filename>linux_ioctl.c</filename>, onde a função <function>linux_ioctl</function> é definida. Esta função simplesmente itera sobre conjuntos de manipuladores ioctl para encontrar um manipulador que implementa um dado comando. A syscall ioctl tem três parâmetros, o file descriptor, comando e um argumento. O comando é um número de 16 bits, que, em teoria, é dividido em alta classe determinante de 8 bits do comando ioctl e 8 bits baixos, que são o comando real dentro do conjunto dado. A emulação aproveita essa divisão. Implementamos manipuladores para cada conjunto, como <function>sound_handler</function> ou <function>disk_handler</function>. Cada manipulador tem um comando máximo e um comando mínimo definido, que é usado para determinar qual manipulador é usado. Existem pequenos problemas com esta abordagem porque <trademark class="registered">Linux</trademark> não usa a divisão definida consistentemente, por isso as ioctls para um conjunto diferente estão dentro de um conjunto ao qual não devem pertencer (ioctls genéricos SCSI dentro do cdrom conjunto, etc.). O FreeBSD atualmente não implementa muitos ioctls do <trademark class="registered">Linux</trademark> (comparado ao NetBSD, por exemplo), mas o plano é portar os do NetBSD. A tendência é usar o ioctls <trademark class="registered">Linux</trademark> mesmo nos drivers nativos do FreeBSD, devido à fácil portabilidade dos aplicativos.
7 months ago
This infrastructure is necessary to avoid races when opening files outside the working directory. Imagine that a process consists of two threads, thread A and thread B. Thread A issues <literal>open(./tmp/foo/bah., flags, mode)</literal> and before returning it gets preempted and thread B runs. Thread B does not care about the needs of thread A and renames or removes <filename>/tmp/foo/</filename>. We got a race. To avoid this we can open <filename>/tmp/foo</filename> and use it as <varname>dirfd</varname> for <function>openat</function> syscall. This also enables user to implement per-thread working directories.
Esta infra-estrutura é necessária para evitar corridas ao abrir arquivos fora do diretório de trabalho. Imagine que um processo consiste em duas threads, thread A e thread B. Thread A emite <literal>open (./tmp/foo/bah., Flags, mode)</literal> e antes de retornar ele se antecipa e a thread B é executada. A thread B não se preocupa com as necessidades da thread A e renomeia ou remove o <filename>/tmp/foo/</filename>. Nós temos uma corrida. Para evitar isso, podemos abrir o <filename>/tmp/foo</filename> e usá-lo como <varname>dirfd</varname> para a syscall <function>openat</function>. Isso também permite que o usuário implemente diretórios de trabalho por thread.
7 months ago
The solution <trademark class="registered">Linux</trademark> 2.6 implements is called futexes. Futexes implement the check for contention in userspace and call kernel primitives only in a case of contention. Thus the typical case takes place without any kernel intervention. This yields reasonably fast and flexible synchronization primitives implementation.
A solução que o <trademark class="registered">Linux</trademark> 2.6 implementa é chamada de futexes. Futexes implementam a verificação de contenção no espaço do usuário e chama primitivas do kernel apenas em um caso de contenção. Assim, o caso típico ocorre sem qualquer intervenção do kernel. Isso produz uma implementação de primitivas de sincronização razoavelmente rápida e flexível.
7 months ago
Browse all translation changes

Statistics

Percent Strings Words Chars
Total 384 12,593 96,977
Translated 100% 384 12,593 96,977
Needs editing 0% 0 0 0
Failing checks 4% 17 1,203 10,212

Last activity

Last change April 18, 2020, 7:20 p.m.
Last author Danilo G. Baio

Daily activity

Daily activity

Weekly activity

Weekly activity