Overview

Project website docs.freebsd.org/en
Translation license BSD 2-Clause "Simplified" License
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Only chosen users can contribute.
  • The translation uses bilingual files.
File mask documentation/content/*/articles/linux-emulation/_index.po
Translation file Download documentation/content/es/articles/linux-emulation/_index.po
Last change March 3, 2024, 10:13 p.m.
Last author Juan David Jaramillo Ortiz

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 396 12,240 77,383
Translated 100% 396 100% 12,240 100% 77,383
Needs editing 0% 0 0% 0 0% 0
Read-only 0% 0 0% 0 0% 0
Failing checks 0% 0 0% 0 0% 0
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 14 changes 0 changes 0 changes 0 changes 7 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 10 changes 0 changes 0 changes 0 changes 2 changes 0 changes
Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

Quick numbers

12,240
Hosted words
396
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

Committed changes

Documentation / articles/linux-emulation/_index — Spanish

Committed changes a year ago
User avatar juanda097

Translation changed

Documentation / articles/linux-emulation/_index — Spanish

Common UNIX(R) 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 `SYSENTER`/`SYSCALL` instructions for ia32). Syscalls are defined by a number. For example in FreeBSD, the syscall number 85 is the man:swapon[2] syscall and the syscall number 132 is man:mkfifo[2]. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependent). Syscalls are synchronous.
ElLa API común de UNIX(R) define llamadas al sistemauna syscall como una forma de ejecutar comandos en el kernel desmitir órdenes desde un proceso del espacio de usuario. al kernel. La implementación más habitual es utilizarcomún es mediante el uso de una interrupción o una instrucción especializada (comopiense en las instrucciones `SYSENTER`/`SYSCALL` enpara ia32). Las llamadas al sistemasyscalls se definen mediante un número. Por ejemplo en FreeBSD, la llamada al sistema número 85 es la llamada al sistema de man:swapon[2] y la llamada al sistema número 132 es man:mkfifo[2]. Algunas llamadas al sistemasyscalls necesitan parámetros, que sone pasados desden del espacio de usuario al espacio de kernell núcleo de varias formmaneras (dependiendo de la implementación). Las llamadas al sistemasyscalls son síncronas.
a year ago
User avatar None

New string to translate

Documentation / articles/linux-emulation/_index — Spanish

1 new string to translate appeared in the translation. a year ago
User avatar None

Resource update

Documentation / articles/linux-emulation/_index — Spanish

The "documentation/content/es/articles/linux-emulation/_index.po" file was changed. a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

Many UNIX(R) derivates implement the man:ptrace[2] syscall to allow various tracking and debugging features. This facility enables the tracing process to obtain various information about the traced process, like register dumps, any memory from the process address space, etc. and also to trace the process like in stepping an instruction or between system entries (syscalls and traps). man:ptrace[2] also lets you set various information in the traced process (registers etc.). man:ptrace[2] is a UNIX(R)-wide standard implemented in most UNIX(R)es around the world.
Muchos derivados de UNIX(R) implementan la llamada al sistema man:ptrace[2] para proporcionar diversas características de depuración y traza. Estas características permiten la traza de un proceso para obtener información valiosa acerca del proceso que es trazado, como volcado de registros, cualquier posición de memoria del espacio de direcciones del proceso, etc. y también para trazar procesos para saltar una instrucción o entre entradas al sistema (llamadas al sistema y traps). man:ptrace[2] también te permite establecer información en los procesos trazados (registros, etc). man:ptrace[2] es un estándar ampliamente disponible e implementado en la mayoría de UNIX(R) en todo el mundo.
a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

The Linux(R) emulation layer is not complete, as some syscalls are not implemented properly and some are not implemented at all. The emulation layer employs a facility to mark unimplemented syscalls with the `DUMMY` macro. These dummy definitions reside in [.filename]#linux_dummy.c# in a form of `DUMMY(syscall);`, which is then translated to various syscall auxiliary files and the implementation consists of printing a message saying that this syscall is not implemented. The `UNIMPL` prototype is not used because we want to be able to identify the name of the syscall that was called to know what syscalls are more important to implement.
La capa de emulación de Linux(R) no es completa ya que algunas llamadas al sistema no están implementadas de forma adecuada y otras no están implementadas en absoluto. La capa de emulación utiliza un método para marcar las llamadas al sistema no implementadas con la macro `DUMMY`. Estas definiciones dummy se encuentran en [.filename]#linux_dummy.c# en la forma `DUMMY(syscall)`, que luego se traduce a varios ficheros auxiliares de llamadas al sistema y cuya implementación consiste en imprimir un mensaje diciendo que la llamada no está implementada. El prototipo `UNIMPL` no se utiliza porque queremos ser capaces de identificar el nombre de la llamada al sistema que fue invocada con el fin de saber qué llamadas al sistema son importantes de implementar.
a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

`sched_bind` is an API used to bind a thread to a particular CPU for all the time it executes the code, until a `sched_unbind` function call does not unbind it. This feature has a key role in situations where you cannot trust the current state of CPUs (for example, at very early stages of boot), as you want to avoid your thread to migrate on inactive CPUs. Since `sched_bind` and `sched_unbind` manipulate internal scheduler structures, they need to be enclosed in `sched_lock` acquisition/releasing when used.
`sched_bind` es una API que se utiliza para vincular un hilo a una CPU en particular durante todo el tiempo que ejecuta el código, hasta que no lo desvincula la llamada a la función `sched_unbind`. Esta función tiene un papel clave en situaciones en las que no puedes confiar en el estado actual de las CPU (por ejemplo, en las primeras etapas del arranque), ya que deseas evitar que tu hilo migre a CPUs inactivas. Como `sched_bin` y `sched_unbind` manipulan las estructuras internas del planificador, es necesario que estén dentro de la adquisición/liberación `sched_lock` cuando se usan.
a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

The FreeBSD kernel has been made preemptive basically to deal with interrupt threads. In fact, to avoid high interrupt latency, time-sharing priority threads can be preempted by interrupt threads (in this way, they do not need to wait to be scheduled as the normal path previews). Preemption, however, introduces new racing points that need to be handled, as well. Often, to deal with preemption, the simplest thing to do is to completely disable it. A critical section defines a piece of code (borderlined by the pair of functions man:critical_enter[9] and man:critical_exit[9], where preemption is guaranteed to not happen (until the protected code is fully executed). This can often replace a lock effectively but should be used carefully to not lose the whole advantage that preemption brings.
El kernel de FreeBSD se ha hecho preemptivo básicamente para tratar con hilos de interrupción. De hecho, para evitar una latencia de interrupción alta, los hilos de tiempo compartido con prioridad pueden ser reemplazados por hilos de interrupción (de esta manera, no necesitan esperar para ser programados como vistas previas de la ruta normal). Un kernel preemptivo, sin embargo, introduce nuevos puntos de carrera que también deben manejarse. A menudo, para hacer frente a la preemptividad, lo más sencillo es desactivarla por completo. Una sección crítica define un fragmento de código (delimitado por el par de funciones man:critical_enter[9] y man:critical_exit[9], donde se garantiza que la preemptividad no ocurrirá hasta que el código protegido se ejecute por completo). Esto a menudo puede reemplazar un lock de manera efectiva, pero debe usarse con cuidado para no perder toda la ventaja que brinda la preemptividad.
a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

Scheduling barriers are intended to be used to drive scheduling of threading. They consist mainly of three different stubs:
Las barreras de programación están destinadas a utilizarse para impulsar la programación multihilo. Consisten principalmente en tres elementos diferentes:
a year ago
User avatar None

String updated in the repository

Documentation / articles/linux-emulation/_index — Spanish

Block locks let waiters to be descheduled and blocked until the lock owner does not drop it and wakes up one or more contenders. To avoid starvation issues, blocking locks do priority propagation from the waiters to the owner. Block locks must be implemented through the turnstile interface and are intended to be the most used kind of locks in the kernel, if no particular conditions are met.
Los locks de bloques permiten que los que esperan sean desprogramados y bloqueados hasta que el propietario del lock no lo libere y despierte a uno o más contendientes. Para evitar problemas de inanición, los locks de bloque propagan la prioridad de los que esperan al propietario. Los locks de bloque deben implementarse a través de la interfaz turnstile y están destinados a ser el tipo de bloqueo más utilizado en el núcleo, si no se cumplen condiciones particulares.
a year ago
Browse all translation changes