New strings to translate a month ago
Resource update a month ago
User avatar None

Source string changed

FreeBSD Doc (Archived) / articles_linux-emulationSpanish

Threaded programs should be written with as little contention on locks as possible. Otherwise, instead of doing useful work the thread just waits on a lock. BecauseAs a result of this, the most well written threaded programs show little locks contention.
a month ago
User avatar None

Source string changed

FreeBSD Doc (Archived) / articles_linux-emulationSpanish

The locking is implemented to be per-subsystem because we do not expect a lot of contention on these. There are two locks: <literal>emul_lock</literal> used to protect manipulating of <literal>linux_emuldata</literal> and <literal>emul_shared_lock</literal> used to manipulate <literal>linux_emuldata_shared</literal>. The <literal>emul_lock</literal> is a nonsleepable blocking mutex while <literal>emul_shared_lock</literal> is a sleepable blocking <literal>sx_lock</literal>. Because ofDue to the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access.
a month ago
User avatar None

Source string changed

FreeBSD Doc (Archived) / articles_linux-emulationSpanish

Because of the describedAs there is a differentce in view knowing whatas what to the idea of a process ID and thread ID is between FreeBSD and <trademark class="registered">Linux</trademark> we have to translate the view somehow. We do it by PID mangling. This means that we fake what a PID (=TGID) and TID (=PID) is between kernel and userland. The rule of thumb is that in kernel (in Linuxulator) PID = PID and TGID = shared -&gt; group pid and to userland we present <literal>PID = shared -&gt; group_pid</literal> and <literal>TID = proc -&gt; p_pid</literal>. The PID member of <literal>linux_emuldata structure</literal> is a FreeBSD PID.
a month ago
User avatar None

Source string changed

FreeBSD Doc (Archived) / articles_linux-emulationSpanish

There are currently two ways to implement threading in FreeBSD. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (<literal>libpthread</literal>) and you can switch at runtime to 1:1 threading (<literal>libthr</literal>). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the <literal>kse_*</literal> family of syscalls while the 1:1 library uses the <literal>thr_*</literal> family of syscalls. Because ofDue to this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by <literal>struct thread</literal>) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on.
a month ago
Futex API
Futex API
2 months ago
Marshall Kirk McKusick - George V. Nevile-Neil. Design and Implementation of the FreeBSD operating system. Addison-Wesley, 2005.
Marshall Kirk McKusick - George V. Nevile-Neil. Diseño e implementación del sistema operativo FreeBSD. Addison-Wesley, 2005.
2 months ago
Literatures
Literaturas
2 months ago
I would like to thank all those people for their advice, code reviews and general support.
Me gustaría agradecer a todas esas personas por sus consejos, revisiones de código y apoyo general.
2 months ago
I cooperated on this project with (in alphabetical order):
Colaboré en este proyecto con (en orden alfabético):
2 months ago
Generally, as <trademark class="registered">Linux</trademark> develops we would like to keep up with their development, implementing newly added syscalls. Splice comes to mind first. Some already implemented syscalls are also heavily crippled, for example <function>mremap</function> and others. Some performance improvements can also be made, finer grained locking and others.
Generalmente, como <trademark class="registered">Linux</trademark> desarrolla nos gustaría mantenernos al día con su desarrollo, implementando syscalls recién agregadas. El empalme viene a la mente primero. Algunas llamadas al sistema ya implementadas también están muy paralizadas, por ejemplo <function>mremap</function> y otros. También se pueden realizar algunas mejoras de rendimiento, bloqueo de grano más fino y otros.
2 months ago
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 really tested. DragonflyBSD has expressed some interest in porting the 2.6 improvements.
El otro objetivo posible es compartir nuestro código con NetBSD y DragonflyBSD. NetBSD tiene algo de soporte para la emulación 2.6 pero está lejos de estar terminado y no se ha probado realmente. DragonflyBSD ha expresado cierto interés en portar las mejoras 2.6.
2 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 ejecutar los programas más importantes sin problemas pronto, por lo que podremos cambiar a la emulación 2.6 por defecto y hacer que Fedora Core 6 sea la linux_base predeterminada porque nuestro Fedora Core 4 que usamos actualmente ya no es compatible.
2 months ago
Future work should focus on fixing the remaining issues with futexes, implement the rest of the *at family of syscalls, fix the signal delivery and possibly implement the <function>epoll</function> and <function>inotify</function> facilities.
El trabajo futuro debe centrarse en solucionar los problemas restantes con futexes, implementar el resto de la familia de llamadas al sistema * at, arreglar la entrega de señal y posiblemente implementar el <function>epoll</function> y <function>inotify</function> instalaciones.
2 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 la emulación 2.6.16 por defecto algún tiempo después del lanzamiento de FreeBSD 7.0 al menos para exponer las partes de la emulación 2.6 para pruebas más amplias. Una vez hecho esto, podemos cambiar a Fedora Core 6 linux_base, que es el plan definitivo.
2 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.
Somos capaces de ejecutar las aplicaciones más utilizadas como <package>www/linux-firefox</package>, <package>net-im/skype</package> y algunos juegos de la colección Ports. Algunos de los programas exhiben un mal comportamiento en la emulación 2.6, pero esto está actualmente bajo investigación y es de esperar que se solucione pronto. La única gran aplicación que se sabe que no funciona es la <trademark class="registered">Linux</trademark> <trademark>Java</trademark> Kit de desarrollo y esto se debe al requisito de <function>epoll</function> instalación que no está directamente relacionada con la <trademark class="registered">Linux</trademark> kernel 2.6.
2 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.
En abril de 2007 el <trademark class="registered">Linux</trademark> La capa de emulación es capaz de emular la <trademark class="registered">Linux</trademark> 2.6.16 kernel bastante bien. Los problemas restantes se refieren a futexes, inacabados * en la familia de llamadas al sistema, entrega de señales problemáticas, falta<function>epoll</function> y <function>inotify</function> y probablemente algunos errores que aún no hemos descubierto. A pesar de esto, somos capaces de ejecutar básicamente todos los <trademark class="registered">Linux</trademark> programas incluidos en FreeBSD Ports Collection con Fedora Core 4 en 2.6.16 y hay algunos informes rudimentarios de éxito con Fedora Core 6 en 2.6.16. Fedora Core 6 linux_base se comprometió recientemente para permitir algunas pruebas adicionales de la capa de emulación y darnos algunas pistas más sobre dónde deberíamos poner nuestro esfuerzo en implementar las cosas que faltan.
2 months ago
Every syscall should be debuggable. For this purpose we introduce a small infrastructure. We have the ldebug facility, which tells whether a given syscall should be debugged (settable via a sysctl). For printing we have LMSG and ARGS macros. Those are used for altering a printable string for uniform debugging messages.
Cada llamada al sistema debería ser depurable. Para ello introducimos una pequeña infraestructura. Tenemos la función ldebug, que indica si una llamada al sistema determinada debe depurarse (configurable mediante un sysctl). Para imprimir tenemos macros LMSG y ARGS. Se utilizan para alterar una cadena imprimible para mensajes de depuración uniformes.
2 months ago
Debugging
Depuración
2 months ago

Search