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

Translation

(itstool) path: sect3/para
English
Common <trademark class="registered">UNIX</trademark> API defines a syscall as a way to issue commands from a user space process to the kernel. The most common implementation is either by using an interrupt or specialized instruction (think of <literal>SYSENTER</literal>/<literal>SYSCALL</literal> instructions for ia32). Syscalls are defined by a number. For example in FreeBSD, the syscall number 85 is the <citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall and the syscall number 132 is <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependant). Syscalls are synchronous.
866/7880 · 788
Context English Spanish State
Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS y VirtualBox son marcas comerciales o marcas comerciales registradas de Sun Microsystems, Inc. en los Estados Unidos y otros países.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol. Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se reclaman como marcas comerciales. Cuando esas designaciones aparecen en este documento, y el Proyecto FreeBSD estaba al tanto del reclamo de marca registrada, las designaciones han sido seguidas por el <quote>™</quote> o el <quote>®</quote> símbolo.
$FreeBSD$
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. Esta tesis de maestría trata sobre la actualización del <trademark class="registered">Linux</trademark> capa de emulación (la llamada <firstterm>Linuxulator</firstterm>). La tarea consistía en actualizar la capa para que coincidiera con la funcionalidad de <trademark class="registered">Linux</trademark> 2.6. Como implementación de referencia, el <trademark class="registered">Linux</trademark>Se eligió el kernel 2.6.16. El concepto se basa libremente en la implementación de NetBSD. La mayor parte del trabajo se realizó en el verano de 2006 como parte del programa para estudiantes de Google Summer of Code. El foco estaba en traer el <firstterm>NPTL</firstterm> (new <trademark class="registered">POSIX</trademark> biblioteca de hilos) en la capa de emulación, incluyendo<firstterm>TLS</firstterm> (hilo de almacenamiento local), <firstterm>futexes</firstterm> (mutex rápidos del espacio de usuario), <firstterm>PID destrozar</firstterm>, y algunas otras cosas menores. Se identificaron y solucionaron muchos pequeños problemas en el proceso. Mi trabajo se integró en el repositorio de fuentes principal de FreeBSD y se enviará en la próxima versión 7.0R. Nosotros, el equipo de desarrollo de la emulación, estamos trabajando para hacer <trademark class="registered">Linux</trademark> 2.6 emulación la capa de emulación predeterminada en FreeBSD.
Introduction Introducción
In the last few years the open source <trademark class="registered">UNIX</trademark> based operating systems started to be widely deployed on server and client machines. Among these operating systems I would like to point out two: FreeBSD, for its BSD heritage, time proven code base and many interesting features and <trademark class="registered">Linux</trademark> for its wide user base, enthusiastic open developer community and support from large companies. FreeBSD tends to be used on server class machines serving heavy duty networking tasks with less usage on desktop class machines for ordinary users. While <trademark class="registered">Linux</trademark> has the same usage on servers, but it is used much more by home based users. This leads to a situation where there are many binary only programs available for <trademark class="registered">Linux</trademark> that lack support for FreeBSD. En los últimos años, el código abierto <trademark class="registered">UNIX</trademark> Los sistemas operativos basados en la tecnología comenzaron a implementarse ampliamente en servidores y máquinas cliente. Entre estos sistemas operativos me gustaría señalar dos: FreeBSD, por su herencia BSD, base de código probado en el tiempo y muchas características interesantes y <trademark class="registered">Linux</trademark> por su amplia base de usuarios, una entusiasta comunidad de desarrolladores abierta y el apoyo de grandes empresas. FreeBSD tiende a usarse en máquinas de clase servidor que sirven para tareas de red de trabajo pesado con menos uso en máquinas de clase de escritorio para usuarios normales. Mientras <trademark class="registered">Linux</trademark> tiene el mismo uso en los servidores, pero los usuarios domésticos lo utilizan mucho más. Esto conduce a una situación en la que hay muchos programas binarios disponibles para <trademark class="registered">Linux</trademark> que carecen de soporte para FreeBSD.
Naturally, a need for the ability to run <trademark class="registered">Linux</trademark> binaries on a FreeBSD system arises and this is what this thesis deals with: the emulation of the <trademark class="registered">Linux</trademark> kernel in the FreeBSD operating system. Naturalmente, la necesidad de poder correr <trademark class="registered">Linux</trademark> binarios en un sistema FreeBSD y esto es de lo que trata esta tesis: la emulación del<trademark class="registered">Linux</trademark>kernel en el sistema operativo FreeBSD.
During the Summer of 2006 Google Inc. sponsored a project which focused on extending the <trademark class="registered">Linux</trademark> emulation layer (the so called Linuxulator) in FreeBSD to include <trademark class="registered">Linux</trademark> 2.6 facilities. This thesis is written as a part of this project. Durante el verano de 2006, Google Inc. patrocinó un proyecto que se centró en ampliar la<trademark class="registered">Linux</trademark> capa de emulación (el llamado Linuxulator) en FreeBSD para incluir <trademark class="registered">Linux</trademark> 2.6 instalaciones. Esta tesis está escrita como parte de este proyecto.
A look inside… Una mirada al interior …
In this section we are going to describe every operating system in question. How they deal with syscalls, trapframes etc., all the low-level stuff. We also describe the way they understand common <trademark class="registered">UNIX</trademark> primitives like what a PID is, what a thread is, etc. In the third subsection we talk about how <trademark class="registered">UNIX</trademark> on <trademark class="registered">UNIX</trademark> emulation could be done in general. En esta sección vamos a describir cada sistema operativo en cuestión. Cómo manejan las llamadas al sistema, los trapframes, etc., todas las cosas de bajo nivel. También describimos la forma en que entienden los<trademark class="registered">UNIX</trademark>primitivas como qué es un PID, qué es un hilo, etc. En la tercera subsección hablamos de cómo<trademark class="registered">UNIX</trademark> en <trademark class="registered">UNIX</trademark>la emulación se podría hacer en general.
What is <trademark class="registered">UNIX</trademark> Que es<trademark class="registered">UNIX</trademark>
<trademark class="registered">UNIX</trademark> is an operating system with a long history that has influenced almost every other operating system currently in use. Starting in the 1960s, its development continues to this day (although in different projects). <trademark class="registered">UNIX</trademark> development soon forked into two main ways: the BSDs and System III/V families. They mutually influenced themselves by growing a common <trademark class="registered">UNIX</trademark> standard. Among the contributions originated in BSD we can name virtual memory, TCP/IP networking, FFS, and many others. The System V branch contributed to SysV interprocess communication primitives, copy-on-write, etc. <trademark class="registered">UNIX</trademark> itself does not exist any more but its ideas have been used by many other operating systems world wide thus forming the so called <trademark class="registered">UNIX</trademark>-like operating systems. These days the most influential ones are <trademark class="registered">Linux</trademark>, Solaris, and possibly (to some extent) FreeBSD. There are in-company <trademark class="registered">UNIX</trademark> derivatives (AIX, HP-UX etc.), but these have been more and more migrated to the aforementioned systems. Let us summarize typical <trademark class="registered">UNIX</trademark> characteristics. <trademark class="registered">UNIX</trademark>es un sistema operativo con una larga historia que ha influido en casi todos los demás sistemas operativos actualmente en uso. A partir de la década de 1960, su desarrollo continúa hasta la actualidad (aunque en diferentes proyectos). <trademark class="registered">UNIX</trademark> El desarrollo pronto se bifurcó en dos formas principales: las familias BSD y System III/V. Se influenciaron mutuamente al cultivar un <trademark class="registered">UNIX</trademark> estándar. Entre las contribuciones originadas en BSD podemos nombrar memoria virtual, redes TCP/IP, FFS y muchas otras. La rama System V contribuyó a las primitivas de comunicación entre procesos de SysV, copia en escritura, etc.. <trademark class="registered">UNIX</trademark> en sí ya no existe, pero sus ideas han sido utilizadas por muchos otros sistemas operativos en todo el mundo, formando así el llamado <trademark class="registered">UNIX</trademark>-como los sistemas operativos. En estos días los más influyentes son<trademark class="registered">Linux</trademark>, Solaris y posiblemente (hasta cierto punto) FreeBSD. Hay en la empresa <trademark class="registered">UNIX</trademark> derivados (AIX, HP-UX, etc.), pero estos se han migrado cada vez más a los sistemas antes mencionados. Resumamos los típicos<trademark class="registered">UNIX</trademark> caracteristicas.
Technical details Detalles técnicos
Every running program constitutes a process that represents a state of the computation. Running process is divided between kernel-space and user-space. Some operations can be done only from kernel space (dealing with hardware etc.), but the process should spend most of its lifetime in the user space. The kernel is where the management of the processes, hardware, and low-level details take place. The kernel provides a standard unified <trademark class="registered">UNIX</trademark> API to the user space. The most important ones are covered below. Cada programa en ejecución constituye un proceso que representa un estado del cálculo. El proceso en ejecución se divide entre el espacio del núcleo y el espacio del usuario. Algunas operaciones solo se pueden realizar desde el espacio del kernel (que se ocupa de hardware, etc.), pero el proceso debería pasar la mayor parte de su vida en el espacio del usuario. El kernel es donde se lleva a cabo la gestión de los procesos, el hardware y los detalles de bajo nivel. El kernel proporciona un estándar unificado<trademark class="registered">UNIX</trademark>API al espacio de usuario. Los más importantes se tratan a continuación.
Communication between kernel and user space process Comunicación entre el kernel y el proceso de espacio de usuario
Common <trademark class="registered">UNIX</trademark> API defines a syscall as a way to issue commands from a user space process to the kernel. The most common implementation is either by using an interrupt or specialized instruction (think of <literal>SYSENTER</literal>/<literal>SYSCALL</literal> instructions for ia32). Syscalls are defined by a number. For example in FreeBSD, the syscall number 85 is the <citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall and the syscall number 132 is <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependant). Syscalls are synchronous. Común <trademark class="registered">UNIX</trademark> La API define una llamada al sistema como una forma de emitir comandos desde un proceso de espacio de usuario al kernel. La implementación más común es usar una interrupción o una instrucción especializada (piense en <literal>SYSENTER</literal><literal>SYSCALL</literal>instrucciones para ia32). Las llamadas al sistema se definen mediante un número. Por ejemplo, en FreeBSD, el número de llamada al sistema 85 es el<citerefentry>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>syscall y el número de syscall 132 es <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry> Algunas llamadas al sistema necesitan parámetros, que se pasan del espacio del usuario al espacio del kernel de varias formas (según la implementación). Las llamadas al sistema son sincrónicas.
Another possible way to communicate is by using a <firstterm>trap</firstterm>. Traps occur asynchronously after some event occurs (division by zero, page fault etc.). A trap can be transparent for a process (page fault) or can result in a reaction like sending a <firstterm>signal</firstterm> (division by zero). Otra forma posible de comunicarse es mediante un<firstterm>trap</firstterm>Las trampas ocurren de forma asincrónica después de que ocurre algún evento (división por cero, falla de página, etc.). Una trampa puede ser transparente para un proceso (error de página) o puede resultar en una reacción como enviar una<firstterm>signal</firstterm> (división por cero).
Communication between processes Comunicación entre procesos
There are other APIs (System V IPC, shared memory etc.) but the single most important API is signal. Signals are sent by processes or by the kernel and received by processes. Some signals can be ignored or handled by a user supplied routine, some result in a predefined action that cannot be altered or ignored. Hay otras API (System V IPC, memoria compartida, etc.) pero la API más importante es la señal. Las señales son enviadas por procesos o por el kernel y recibidas por procesos. Algunas señales pueden ser ignoradas o manejadas por una rutina proporcionada por el usuario, otras dan como resultado una acción predefinida que no se puede alterar ni ignorar.
Process management Gestión de proceso
Kernel instances are processed first in the system (so called init). Every running process can create its identical copy using the <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Some slightly modified versions of this syscall were introduced but the basic semantic is the same. Every running process can morph into some other process using the <citerefentry><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry> syscall. Some modifications of this syscall were introduced but all serve the same basic purpose. Processes end their lives by calling the <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Every process is identified by a unique number called PID. Every process has a defined parent (identified by its PID). Las instancias de kernel se procesan primero en el sistema (llamado init). Cada proceso en ejecución puede crear su copia idéntica utilizando el <citerefentry><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Se introdujeron algunas versiones ligeramente modificadas de esta llamada al sistema, pero la semántica básica es la misma. Cada proceso en ejecución puede transformarse en algún otro proceso utilizando el <citerefentry><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry> syscall. Se introdujeron algunas modificaciones de esta llamada al sistema, pero todas tienen el mismo propósito básico. Los procesos terminan sus vidas llamando al <citerefentry><refentrytitle>exit</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall. Cada proceso está identificado por un número único llamado PID. Cada proceso tiene un padre definido (identificado por su PID).
Thread management Gestión de subprocesos
Traditional <trademark class="registered">UNIX</trademark> does not define any API nor implementation for threading, while <trademark class="registered">POSIX</trademark> defines its threading API but the implementation is undefined. Traditionally there were two ways of implementing threads. Handling them as separate processes (1:1 threading) or envelope the whole thread group in one process and managing the threading in userspace (1:N threading). Comparing main features of each approach: Tradicional<trademark class="registered">UNIX</trademark>no define ninguna API ni implementación para subprocesos, mientras que<trademark class="registered">POSIX</trademark>define su API de subprocesos, pero la implementación no está definida. Tradicionalmente, había dos formas de implementar subprocesos. Manejarlos como procesos separados (subprocesos 1: 1) o envolver todo el grupo de subprocesos en un proceso y administrar el subproceso en el espacio de usuario (subprocesos 1: N). Comparación de las principales características de cada enfoque:
1:1 threading Roscado 1: 1
- heavyweight threads - hilos de peso pesado
- the scheduling cannot be altered by the user (slightly mitigated by the <trademark class="registered">POSIX</trademark> API) - la programación no puede ser alterada por el usuario (levemente mitigado por el<trademark class="registered">POSIX</trademark>API)
+ no syscall wrapping necessary + no es necesario envolver syscall
+ can utilize multiple CPUs + puede utilizar varias CPU
1:N threading 1: N roscado
+ lightweight threads + hilos ligeros
+ scheduling can be easily altered by the user + el usuario puede modificar fácilmente la programación

Loading…

User avatar Aaron

New translation

FreeBSD Doc / articles_linux-emulation — Spanish

Common <trademark class="registered">UNIX</trademark> API defines a syscall as a way to issue commands from a user space process to the kernel. The most common implementation is either by using an interrupt or specialized instruction (think of <literal>SYSENTER</literal>/<literal>SYSCALL</literal> instructions for ia32). Syscalls are defined by a number. For example in FreeBSD, the syscall number 85 is the <citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall and the syscall number 132 is <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependant). Syscalls are synchronous.
Común <trademark class="registered">UNIX</trademark> La API define una llamada al sistema como una forma de emitir comandos desde un proceso de espacio de usuario al kernel. La implementación más común es usar una interrupción o una instrucción especializada (piense en <literal>SYSENTER</literal><literal>SYSCALL</literal>instrucciones para ia32). Las llamadas al sistema se definen mediante un número. Por ejemplo, en FreeBSD, el número de llamada al sistema 85 es el<citerefentry>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>syscall y el número de syscall 132 es <citerefentry><refentrytitle>mkfifo</refentrytitle><manvolnum>2</manvolnum></citerefentry> Algunas llamadas al sistema necesitan parámetros, que se pasan del espacio del usuario al espacio del kernel de varias formas (según la implementación). Las llamadas al sistema son sincrónicas.
2 months ago
Browse all component changes

Things to check

XML syntax

The translation is not valid XML

Reset

Glossary

English Spanish
trademark marca comercial FreeBSD Doc

Source information

Source string comment
(itstool) path: sect3/para
Source string location
article.translate.xml:159
String age
10 months ago
Source string age
10 months ago
Translation file
articles/es_ES/linux-emulation.po, string 27