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

Translation

(itstool) path: sect3/para
English
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:
552/4930 · 493
Context English Spanish State
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
- syscalls must be wrapped - las llamadas al sistema deben estar envueltas
- cannot utilize more than one CPU - no puede utilizar más de una CPU
What is FreeBSD? ¿Qué es FreeBSD?
The FreeBSD project is one of the oldest open source operating systems currently available for daily use. It is a direct descendant of the genuine <trademark class="registered">UNIX</trademark> so it could be claimed that it is a true <trademark class="registered">UNIX</trademark> although licensing issues do not permit that. The start of the project dates back to the early 1990's when a crew of fellow BSD users patched the 386BSD operating system. Based on this patchkit a new operating system arose named FreeBSD for its liberal license. Another group created the NetBSD operating system with different goals in mind. We will focus on FreeBSD. El proyecto FreeBSD es uno de los sistemas operativos de código abierto más antiguos disponibles actualmente para uso diario. Es un descendiente directo del genuino<trademark class="registered">UNIX</trademark>por lo que podría afirmarse que es un verdadero<trademark class="registered">UNIX</trademark>aunque los problemas de licencias no lo permiten. El inicio del proyecto se remonta a principios de la década de 1990 cuando un equipo de usuarios de BSD parchó el sistema operativo 386BSD. Basado en este patchkit, surgió un nuevo sistema operativo llamado FreeBSD por su licencia liberal. Otro grupo creó el sistema operativo NetBSD con diferentes objetivos en mente. Nos centraremos en FreeBSD.
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: FreeBSD es un moderno<trademark class="registered">UNIX</trademark>sistema operativo basado en todas las características de<trademark class="registered">UNIX</trademark>Multitarea preventiva, instalaciones multiusuario, redes TCP / IP, protección de memoria, soporte de multiprocesamiento simétrico, memoria virtual con VM fusionada y caché de búfer, todo está ahí. Una de las características interesantes y extremadamente útiles es la capacidad de emular otros<trademark class="registered">UNIX</trademark>como los sistemas operativos. A diciembre de 2006 y al desarrollo 7-CURRENT, se admiten las siguientes funcionalidades de emulación:
FreeBSD/i386 emulation on FreeBSD/amd64 Emulación FreeBSD/i386 en FreeBSD/amd64
FreeBSD/i386 emulation on FreeBSD/ia64 Emulación FreeBSD/i386 en FreeBSD/ia64

Loading…

User avatar Aaron

New translation

FreeBSD Doc / articles_linux-emulation — Spanish

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:
2 months ago
User avatar None

New source string

FreeBSD Doc / articles_linux-emulation — Spanish

New source string a year ago
Browse all component changes

Glossary

English Spanish
trademark marca comercial FreeBSD Doc

Source information

Source string comment
(itstool) path: sect3/para
Source string location
article.translate.xml:210
String age
a year ago
Source string age
a year ago
Translation file
articles/es_ES/linux-emulation.po, string 34