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

Translation

(itstool) path: sect2/para
English
The kernel keeps for each process a <emphasis>descriptor table</emphasis>, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine.
Context English Spanish State
When pages are remapped to new virtual-memory addresses, most memory-management hardware requires that the hardware address-translation cache be purged selectively. The cache purges are often slow. The net effect is that remapping is slower than copying for blocks of data less than 4 to 8 Kbyte. Cuando las páginas se reasignan a nuevas direcciones de memoria virtual, la mayoría del hardware de administración de memoria requiere que la caché de traducción de direcciones del hardware se purgue de forma selectiva. Las purgas de caché suelen ser lentas. El efecto neto es que la reasignación es más lenta que la copia de bloques de datos de menos de 4 a 8 Kbyte.
The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes. The <emphasis>mmap</emphasis> interface provides a way for both of these tasks to be done without copying. Los mayores incentivos para el mapeo de memoria son las necesidades de acceder a archivos grandes y pasar grandes cantidades de datos entre procesos. los <emphasis>mmap</emphasis> La interfaz proporciona una forma de realizar ambas tareas sin realizar copias.
Memory Management Inside the Kernel Gestión de la memoria dentro del kernel
The kernel often does allocations of memory that are needed for only the duration of a single system call. In a user process, such short-term memory would be allocated on the run-time stack. Because the kernel has a limited run-time stack, it is not feasible to allocate even moderate-sized blocks of memory on it. Consequently, such memory must be allocated through a more dynamic mechanism. For example, when the system must translate a pathname, it must allocate a 1-Kbyte buffer to hold the name. Other blocks of memory must be more persistent than a single system call, and thus could not be allocated on the stack even if there was space. An example is protocol-control blocks that remain throughout the duration of a network connection. El kernel a menudo realiza asignaciones de memoria que son necesarias solo durante la duración de una única llamada al sistema. En un proceso de usuario, dicha memoria a corto plazo se asignaría en la pila de tiempo de ejecución. Debido a que el kernel tiene una pila de tiempo de ejecución limitada, no es factible asignarle bloques de memoria de tamaño moderado. En consecuencia, dicha memoria debe asignarse mediante un mecanismo más dinámico. Por ejemplo, cuando el sistema debe traducir un nombre de ruta, debe asignar un búfer de 1 Kbyte para contener el nombre. Otros bloques de memoria deben ser más persistentes que una sola llamada al sistema y, por lo tanto, no se podrían asignar en la pila incluso si hubiera espacio. Un ejemplo son los bloques de control de protocolo que permanecen durante la duración de una conexión de red.
Demands for dynamic memory allocation in the kernel have increased as more services have been added. A generalized memory allocator reduces the complexity of writing code inside the kernel. Thus, the 4.4BSD kernel has a single memory allocator that can be used by any part of the system. It has an interface similar to the C library routines <emphasis>malloc</emphasis> and <emphasis>free</emphasis> that provide memory allocation to application programs <xref linkend="biblio-mckusick-2"/>. Like the C library interface, the allocation routine takes a parameter specifying the size of memory that is needed. The range of sizes for memory requests is not constrained; however, physical memory is allocated and is not paged. The free routine takes a pointer to the storage being freed, but does not require the size of the piece of memory being freed. Las demandas de asignación de memoria dinámica en el kernel han aumentado a medida que se han agregado más servicios. Un asignador de memoria generalizado reduce la complejidad de escribir código dentro del kernel. Por lo tanto, el núcleo 4.4BSD tiene un único asignador de memoria que puede ser utilizado por cualquier parte del sistema. Tiene una interfaz similar a las rutinas de la biblioteca C <emphasis>malloc</emphasis> y <emphasis>free</emphasis> que proporcionan asignación de memoria a programas de aplicación <xref linkend="biblio-mckusick-2"/>. Al igual que la interfaz de la biblioteca C, la rutina de asignación toma un parámetro que especifica el tamaño de memoria que se necesita. El rango de tamaños para las solicitudes de memoria no está restringido; sin embargo, la memoria física está asignada y no paginada. La rutina libre toma un puntero al almacenamiento que se libera, pero no requiere el tamaño de la pieza de memoria que se libera.
I/O System Sistema de E/S
The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. There are no <emphasis>access methods</emphasis> and no <emphasis>control blocks</emphasis> in a typical UNIX user process. El modelo básico del sistema de E/S de UNIX es una secuencia de bytes a la que se puede acceder de forma aleatoria o secuencial. No existen <emphasis>access methods</emphasis> y no<emphasis>control blocks</emphasis> en un proceso de usuario típico de UNIX.
Different programs expect various levels of structure, but the kernel does not impose structure on I/O. For instance, the convention for text files is lines of ASCII characters separated by a single newline character (the ASCII line-feed character), but the kernel knows nothing about this convention. For the purposes of most programs, the model is further simplified to being a stream of data bytes, or an <emphasis>I/O stream</emphasis>. It is this single common data form that makes the characteristic UNIX tool-based approach work <xref linkend="biblio-kernighan"/>. An I/O stream from one program can be fed as input to almost any other program. (This kind of traditional UNIX I/O stream should not be confused with the Eighth Edition stream I/O system or with the System V, Release 3 STREAMS, both of which can be accessed as traditional I/O streams.) Los diferentes programas esperan varios niveles de estructura, pero el núcleo no impone una estructura a la E/S. Por ejemplo, la convención para archivos de texto son líneas de caracteres ASCII separadas por un carácter de nueva línea (el carácter de avance de línea ASCII), pero el núcleo no sabe nada sobre esta convención. Para los propósitos de la mayoría de los programas, el modelo se simplifica aún más para ser un flujo de bytes de datos o un <emphasis>I/O stream</emphasis>. Es este único formulario de datos común el que hace que el enfoque basado en herramientas característico de UNIX funcione. <xref linkend="biblio-kernighan"/>. Un flujo de E / S de un programa se puede alimentar como entrada a casi cualquier otro programa. (Este tipo de flujo de E / S tradicional de UNIX no debe confundirse con el sistema de E / S de flujo de la octava edición o con los STREAMS de System V, versión 3, a los cuales se puede acceder como flujos de E/S tradicionales).
Descriptors and I/O Descriptores y E/S
UNIX processes use <emphasis>descriptors</emphasis> to reference I/O streams. Descriptors are small unsigned integers obtained from the <emphasis>open</emphasis> and <emphasis>socket</emphasis> system calls. The <emphasis>open</emphasis> system call takes as arguments the name of a file and a permission mode to specify whether the file should be open for reading or for writing, or for both. This system call also can be used to create a new, empty file. A <emphasis>read</emphasis> or <emphasis>write</emphasis> system call can be applied to a descriptor to transfer data. The <emphasis>close</emphasis> system call can be used to deallocate any descriptor.
Descriptors represent underlying objects supported by the kernel, and are created by system calls specific to the type of object. In 4.4BSD, three kinds of objects can be represented by descriptors: files, pipes, and sockets. Los descriptores representan objetos subyacentes admitidos por el kernel y se crean mediante llamadas al sistema específicas para el tipo de objeto. En 4.4BSD, se pueden representar tres tipos de objetos mediante descriptores: archivos, tuberías y sockets.
A <emphasis>file</emphasis> is a linear array of bytes with at least one name. A file exists until all its names are deleted explicitly and no process holds a descriptor for it. A process acquires a descriptor for a file by opening that file's name with the <emphasis>open</emphasis> system call. I/O devices are accessed as files.
A <emphasis>pipe</emphasis> is a linear array of bytes, as is a file, but it is used solely as an I/O stream, and it is unidirectional. It also has no name, and thus cannot be opened with <emphasis>open</emphasis>. Instead, it is created by the <emphasis>pipe</emphasis> system call, which returns two descriptors, one of which accepts input that is sent to the other descriptor reliably, without duplication, and in order. The system also supports a named pipe or FIFO. A FIFO has properties identical to a pipe, except that it appears in the filesystem; thus, it can be opened using the <emphasis>open</emphasis> system call. Two processes that wish to communicate each open the FIFO: One opens it for reading, the other for writing.
A <emphasis>socket</emphasis> is a transient object that is used for interprocess communication; it exists only as long as some process holds a descriptor referring to it. A socket is created by the <emphasis>socket</emphasis> system call, which returns a descriptor for it. There are different kinds of sockets that support various communication semantics, such as reliable delivery of data, preservation of message ordering, and preservation of message boundaries.
In systems before 4.2BSD, pipes were implemented using the filesystem; when sockets were introduced in 4.2BSD, pipes were reimplemented as sockets. En los sistemas anteriores a 4.2BSD, las tuberías se implementaron utilizando el sistema de archivos; cuando se introdujeron los enchufes en 4.2BSD, las tuberías se volvieron a implementar como enchufes.
The kernel keeps for each process a <emphasis>descriptor table</emphasis>, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine.
Every valid descriptor has an associated <emphasis>file offset</emphasis> in bytes from the beginning of the object. Read and write operations start at this offset, which is updated after each data transfer. For objects that permit random access, the file offset also may be set with the <emphasis>lseek</emphasis> system call. Ordinary files permit random access, and some devices do, as well. Pipes and sockets do not. Cada descriptor válido tiene asociado un <emphasis>file offset</emphasis> en bytes desde el principio del objeto. Las operaciones de lectura y escritura comienzan en este desplazamiento, que se actualiza después de cada transferencia de datos. Para los objetos que permiten el acceso aleatorio, el desplazamiento del archivo también se puede establecer con el <emphasis>lseek</emphasis> llamada al sistema. Los archivos ordinarios permiten el acceso aleatorio, y algunos dispositivos también lo hacen. Las tuberías y los enchufes no.
When a process terminates, the kernel reclaims all the descriptors that were in use by that process. If the process was holding the final reference to an object, the object's manager is notified so that it can do any necessary cleanup actions, such as final deletion of a file or deallocation of a socket. Cuando un proceso termina, el kernel recupera todos los descriptores que estaban en uso por ese proceso. Si el proceso contenía la referencia final a un objeto, se notifica al administrador del objeto para que pueda realizar las acciones de limpieza necesarias, como la eliminación final de un archivo o la desasignación de un socket.
Descriptor Management Gestión de descriptores
Most processes expect three descriptors to be open already when they start running. These descriptors are 0, 1, 2, more commonly known as <emphasis>standard input</emphasis>, <emphasis>standard output</emphasis>, and <emphasis>standard error</emphasis>, respectively. Usually, all three are associated with the user's terminal by the login process (see Section 14.6) and are inherited through <emphasis>fork</emphasis> and <emphasis>exec</emphasis> by processes run by the user. Thus, a program can read what the user types by reading standard input, and the program can send output to the user's screen by writing to standard output. The standard error descriptor also is open for writing and is used for error output, whereas standard output is used for ordinary output.
These (and other) descriptors can be mapped to objects other than the terminal; such mapping is called <emphasis>I/O redirection</emphasis>, and all the standard shells permit users to do it. The shell can direct the output of a program to a file by closing descriptor 1 (standard output) and opening the desired output file to produce a new descriptor 1. It can similarly redirect standard input to come from a file by closing descriptor 0 and opening the file.
Pipes allow the output of one program to be input to another program without rewriting or even relinking of either program. Instead of descriptor 1 (standard output) of the source program being set up to write to the terminal, it is set up to be the input descriptor of a pipe. Similarly, descriptor 0 (standard input) of the sink program is set up to reference the output of the pipe, instead of the terminal keyboard. The resulting set of two processes and the connecting pipe is known as a <emphasis>pipeline</emphasis>. Pipelines can be arbitrarily long series of processes connected by pipes. Las tuberías permiten que la salida de un programa se introduzca en otro programa sin tener que volver a escribir o incluso volver a vincular ninguno de los programas. En lugar de configurar el descriptor 1 (salida estándar) del programa fuente para escribir en el terminal, se configura para ser el descriptor de entrada de una tubería. De manera similar, el descriptor 0 (entrada estándar) del programa de sumidero está configurado para hacer referencia a la salida de la tubería, en lugar del teclado del terminal. El conjunto resultante de dos procesos y la tubería de conexión se conoce como <emphasis>pipeline</emphasis>. Las Pipelines pueden ser series arbitrariamente largas de procesos conectados por tuberías.
The <emphasis>open</emphasis>, <emphasis>pipe</emphasis>, and <emphasis>socket</emphasis> system calls produce new descriptors with the lowest unused number usable for a descriptor. For pipelines to work, some mechanism must be provided to map such descriptors into 0 and 1. The <emphasis>dup</emphasis> system call creates a copy of a descriptor that points to the same file-table entry. The new descriptor is also the lowest unused one, but if the desired descriptor is closed first, <emphasis>dup</emphasis> can be used to do the desired mapping. Care is required, however: If descriptor 1 is desired, and descriptor 0 happens also to have been closed, descriptor 0 will be the result. To avoid this problem, the system provides the <emphasis>dup2</emphasis> system call; it is like <emphasis>dup</emphasis>, but it takes an additional argument specifying the number of the desired descriptor (if the desired descriptor was already open, <emphasis>dup2</emphasis> closes it before reusing it).
Devices Dispositivos
Hardware devices have filenames, and may be accessed by the user via the same system calls used for regular files. The kernel can distinguish a <emphasis>device special file</emphasis> or <emphasis>special file</emphasis>, and can determine to what device it refers, but most processes do not need to make this determination. Terminals, printers, and tape drives are all accessed as though they were streams of bytes, like 4.4BSD disk files. Thus, device dependencies and peculiarities are kept in the kernel as much as possible, and even in the kernel most of them are segregated in the device drivers. Los dispositivos de hardware tienen nombres de archivo y el usuario puede acceder a ellos a través de las mismas llamadas al sistema que se utilizan para los archivos normales. El kernel puede distinguir un <emphasis>device special file</emphasis> o <emphasis>special file</emphasis>, y puede determinar a qué dispositivo se refiere, pero la mayoría de los procesos no necesitan hacer esta determinación. Se accede a los terminales, impresoras y unidades de cinta como si fueran flujos de bytes, como archivos de disco 4.4BSD. Por lo tanto, las dependencias y peculiaridades de los dispositivos se mantienen en el kernel tanto como sea posible, e incluso en el kernel la mayoría de ellas están segregadas en los controladores de dispositivos.
Hardware devices can be categorized as either <emphasis>structured</emphasis> or <emphasis>unstructured</emphasis>; they are known as <emphasis>block</emphasis> or <emphasis>character</emphasis> devices, respectively. Processes typically access devices through <emphasis>special files</emphasis> in the filesystem. I/O operations to these files are handled by kernel-resident software modules termed <emphasis>device drivers</emphasis>. Most network-communication hardware devices are accessible through only the interprocess-communication facilities, and do not have special files in the filesystem name space, because the <emphasis>raw-socket</emphasis> interface provides a more natural interface than does a special file.
Structured or block devices are typified by disks and magnetic tapes, and include most random-access devices. The kernel supports read-modify-write-type buffering actions on block-oriented structured devices to allow the latter to be read and written in a totally random byte-addressed fashion, like regular files. Filesystems are created on block devices. Los dispositivos estructurados o en bloque se caracterizan por discos y cintas magnéticas, e incluyen la mayoría de los dispositivos de acceso aleatorio. El kernel admite acciones de almacenamiento en búfer de tipo lectura-modificación-escritura en dispositivos estructurados orientados a bloques para permitir que estos últimos se lean y escriban de forma totalmente aleatoria con direcciones de bytes, como archivos normales. Los sistemas de archivos se crean en dispositivos de bloque.
Unstructured devices are those devices that do not support a block structure. Familiar unstructured devices are communication lines, raster plotters, and unbuffered magnetic tapes and disks. Unstructured devices typically support large block I/O transfers. Los dispositivos no estructurados son aquellos dispositivos que no admiten una estructura de bloques. Los dispositivos no estructurados familiares son las líneas de comunicación, los trazadores de trama y las cintas y discos magnéticos sin búfer. Los dispositivos no estructurados suelen admitir transferencias de I/O de bloques grandes.
Unstructured files are called <emphasis>character devices</emphasis> because the first of these to be implemented were terminal device drivers. The kernel interface to the driver for these devices proved convenient for other devices that were not block structured.
Device special files are created by the <emphasis>mknod</emphasis> system call. There is an additional system call, <emphasis>ioctl</emphasis>, for manipulating the underlying device parameters of special files. The operations that can be done differ for each device. This system call allows the special characteristics of devices to be accessed, rather than overloading the semantics of other system calls. For example, there is an <emphasis>ioctl</emphasis> on a tape drive to write an end-of-tape mark, instead of there being a special or modified version of <emphasis>write</emphasis>.
Socket IPC Socket IPC
User avatar Aaron

Suggestion added

El núcleo mantiene para cada proceso un <emphasis>descriptor table</emphasis>, que es una tabla que usa el kernel para traducir la representación externa de un descriptor en una representación interna. (El descriptor es simplemente un índice en esta tabla). La tabla de descriptores de un proceso se hereda del padre de ese proceso y, por lo tanto, también se hereda el acceso a los objetos a los que se refieren los descriptores. Las principales formas en que un proceso puede obtener un descriptor son abriendo o creando un objeto, y por herencia del proceso padre. Además, socket IPC permite el paso de descriptores en mensajes entre procesos no relacionados en la misma máquina.

Suggested change:

El núcleo mantiene para cada proceso un <emphasis>descriptor table</emphasis>, que es una tabla que usa el kernel para traducir la representación externa de un descriptor en una representación interna. (El descriptor es simplemente un índice en esta tabla). La tabla de descriptores de un proceso se hereda del padre de ese proceso y, por lo tanto, también se hereda el acceso a los objetos a los que se refieren los descriptores. Las principales formas en que un proceso puede obtener un descriptor son abriendo o creando un objeto, y por herencia del proceso padre. Además, socket IPC permite el paso de descriptores en mensajes entre procesos no relacionados en la misma máquina.
2 months ago

Loading…

The kernel keeps for each process a <emphasis>descriptor table</emphasis>, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine.
El núcleo mantiene para cada proceso un <emphasis>descriptor table</emphasis>, que es una tabla que usa el kernel para traducir la representación externa de un descriptor en una representación interna. (El descriptor es simplemente un índice en esta tabla). La tabla de descriptores de un proceso se hereda del padre de ese proceso y, por lo tanto, también se hereda el acceso a los objetos a los que se refieren los descriptores. Las principales formas en que un proceso puede obtener un descriptor son abriendo o creando un objeto, y por herencia del proceso padre. Además, socket IPC permite el paso de descriptores en mensajes entre procesos no relacionados en la misma máquina.
2 months ago
Browse all component changes

Things to check

Suggestions

There is 1 suggestion for this string.

View

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Source string location
book.translate.xml:1234
String age
2 months ago
Source string age
a year ago
Translation file
books/es/design-44bsd.po, string 190