<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="es">
		<id>https://1984.lsi.us.es/wiki-ssoo/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rafesclir</id>
		<title>Wiki de Sistemas Operativos - Contribuciones del usuario [es]</title>
		<link rel="self" type="application/atom+xml" href="https://1984.lsi.us.es/wiki-ssoo/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rafesclir"/>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php/Especial:Contribuciones/Rafesclir"/>
		<updated>2026-04-08T16:36:41Z</updated>
		<subtitle>Contribuciones del usuario</subtitle>
		<generator>MediaWiki 1.29.0</generator>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Lista_de_contribuidores_de_la_wiki_en_2014-2015&amp;diff=3044</id>
		<title>Lista de contribuidores de la wiki en 2014-2015</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Lista_de_contribuidores_de_la_wiki_en_2014-2015&amp;diff=3044"/>
				<updated>2015-01-29T11:24:50Z</updated>
		
		<summary type="html">&lt;p&gt;Rafesclir: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* Pérez Morral, Mateo (Usuario: matpermor)&lt;br /&gt;
* Rodríguez Valencia, Enrique (Usuario: erodriguez19)&lt;br /&gt;
* Manzano Rueda, Álvaro (Usuario: alvmanrue)&lt;br /&gt;
* Mantas Nakhai, Roberto (Usuario: robmannak)&lt;br /&gt;
* Bernal Bueno, Leonardo Juan (Usuario: leoberbue)&lt;br /&gt;
* Jiménez Odero, Ricardo (Usuario: Ricjimode)&lt;br /&gt;
* Escudero Lirio, Rafael (Usuario: Rafesclir)&lt;/div&gt;</summary>
		<author><name>Rafesclir</name></author>	</entry>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Estructura_t%C3%ADpica_de_dispositivo_E/S&amp;diff=3043</id>
		<title>Estructura típica de dispositivo E/S</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Estructura_t%C3%ADpica_de_dispositivo_E/S&amp;diff=3043"/>
				<updated>2015-01-29T11:23:19Z</updated>
		
		<summary type="html">&lt;p&gt;Rafesclir: /* DMA */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;En general, la estructura típica de un dispositivo de entrada/salida está dividida en tres partes:&lt;br /&gt;
&lt;br /&gt;
* '''Adaptador de Entrada/Salida del ordenador, o interfaz del bus:''' Se encarga de traducir las señales al dialecto empleado por el bus del ordenador. Algunos ejemplos de interfaces de este tipo son los buses PCI, PCMCIA, USB, PCI-express o SATA entre muchos otros.&lt;br /&gt;
* '''Control del dispositivo, o puerto de lectura/escritura:''' Ofrece una interfaz que es empleada por el gestor de dispositivos para gobernar el dispositivo, que dispone de:&lt;br /&gt;
**Registros de órdenes&lt;br /&gt;
**Registros de estado&lt;br /&gt;
**Registros de lectura/escritura, o alternativamente una pequeña memoria propia.&lt;br /&gt;
* '''Adaptador de Entrada/Salida del dispositivo, o interfaz del dispositivo:''' Se encarga de traducir las señales al dialecto empleado por el dispositivo.&lt;br /&gt;
&lt;br /&gt;
Cuanto más elaborado sea el puerto de lectura/escritura, mayor rendimiento se puede llegar a alcanzar, puesto que el gestor de dispositivo será más sencillo (y eso implica menor número de instrucciones a ejecutar en el gestor de dispositivo).&lt;br /&gt;
&lt;br /&gt;
La conexión existente entre el procesador y el dispositivo de E/S queda resumida de la siguiente manera:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Archivo:EstructuraES.gif|Estructura del dispositivo]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Gestor de dispositivos =&lt;br /&gt;
&lt;br /&gt;
El gestor de dispositivo, popularmente conocido por la palabra inglesa ''driver'', es la parte del sistema operativo que se encarga de gobernar un cierto dispositivo o una familia de dispositivos de naturaleza similar. El gestor de dispositivo se trata de una pieza de software que conoce los detalles de bajo nivel del dispositivo. De esta manera el driver hace uso del conjunto de instrucciones que ofrece el puerto de E/S, los registros de estado y de lectura&lt;br /&gt;
y escritura, para gobernar el dispositivo. Si el fabricante del dispositivo no ofrece un ''driver'' para un cierto sistema operativo, el dispositivo y los recursos que ofrece no puede ser gestionado por el sistema operativo. Por lo general el fabricante de un dispositivo desarrolla el gestor de dispositivo para los sistemas operativos mayoritarios (i.e. Windows y Linux) para asegurar que su dispositivo alcanza la mayor cuota de usuarios posibles.&lt;br /&gt;
&lt;br /&gt;
Los gestores de dispositivos representan en torno al 70% de los sistemas operativos&amp;lt;ref&amp;gt;Construction of a Highly Dependable Operating System, Proc. 6th European Dependable Computing Conference (EDCC-6), pp. 3-12, Oct. 2006&amp;lt;/ref&amp;gt;. Por lo general, en los sistemas operativos monolíticos se ejecutan en el espacio del núcleo del sistema operativo por razones de rendimiento. Por tanto, se ejecutan en modo privilegiado, así un error de programación en un ''driver'' lleve a un cuelgue completo del sistema con casi total seguridad. Se estima que en torno al 85% de cuelgues de Microsoft Windows XP &amp;lt;ref&amp;gt;Recovering Device Drivers, Proc. OSDI '04, pp. 1-16, 2004&amp;lt;/ref&amp;gt;se debe a errores de programación en ''drivers''.&lt;br /&gt;
&lt;br /&gt;
No obstante, en sistemas operativos convencionales como Windows, Linux y Mac, existen mecanismos que permiten ejecutar ''drivers'' como procesos de usuario, tal y como sucede en sistemas operativo de tipo micronúcleo. De esta manera, un error de programación no produce el cuelgue del sistema completo. No obstante, dichos gestores de dispositivos se limitan a dispositivos particularmente lentos en los que la tasa de transferencia de datos es baja y los tiempos de respuesta del dispositivo son altos, por ejemplo, los gestores de dispositivos para lectores de tarjetas inteligentes (smartcards, lo que incluye las tarjetas SIM que se emplean en telefonía móvil) en Linux funcionan en espacio de usuario.&lt;br /&gt;
&lt;br /&gt;
==DMA==&lt;br /&gt;
'''DMA''' (''Direct memory access'') es un dispositivo capaz de '''transferir datos''' entre la memoria principal y el dispositivo de E/S. El procesador le ordena hacer transferencias, y cuando termina, produce una interrupción.&lt;br /&gt;
&lt;br /&gt;
Gracias a esta característica, diferentes dispositivos con distintas velocidades pueden comunicarse sin que la CPU, que es independiente al acceso a memoria principal, sufra una gran carga de interrupciones. &lt;br /&gt;
&lt;br /&gt;
Pueden estar '''integrados''' tanto en el sistema como en el propio dispositivo.&lt;br /&gt;
&lt;br /&gt;
Frecuentemente son '''multicanal''', por lo que se pueden tener varias transferencias en curso simultáneamente.&lt;br /&gt;
&lt;br /&gt;
Pueden soportar transferencias de memoria a memoria.&lt;br /&gt;
&lt;br /&gt;
==Notas==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Rafesclir</name></author>	</entry>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Dise%C3%B1o_modular_E/S&amp;diff=3031</id>
		<title>Diseño modular E/S</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Dise%C3%B1o_modular_E/S&amp;diff=3031"/>
				<updated>2015-01-15T16:45:47Z</updated>
		
		<summary type="html">&lt;p&gt;Rafesclir: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;El diseño de software de entrada/salida nos plantea las siguientes necesidades:&lt;br /&gt;
* Modelar un '''diseño por capas o estratos''', dotando de una abstracción que oculte las peculiaridades de los dispositivos a las capas superiores, que deben ofrecer una interfaz homogénea. &lt;br /&gt;
&lt;br /&gt;
* Hacer a los '''programas independientes de los dispositivos''', que no tienen por qué conocer el soporte que manejan. Esto es deseable en cuanto a que el fabricante del dispositivo podría dejar de fabricar el dispositivo, por tanto, el proceso tendría que ser reescrito para soportar el nuevo dispositivo. De igual manera, si el dispositivo para el que está diseñado el proceso que conoce los detalles de bajo nivel no está disponible en el sistema, nuestro proceso quedaría inservible.&lt;br /&gt;
&lt;br /&gt;
* Dar un '''criterio uniforme de denominación''': En sistemas Unix, por ejemplo, se trata a cada dispositivo como a un fichero&lt;br /&gt;
&lt;br /&gt;
* '''Tratamiento de errores''' lo más '''próximo''' posible a su '''origen''': si un estrato detecta un error y puede solucionarlo, lo oculta a los niveles superiores. Si no, informa a nivel superior. &lt;br /&gt;
&lt;br /&gt;
* Forzar a que un '''proceso tenga que pasar por el sistema operativo''', que es quien garantiza que el reparto de recursos es equitativo. Si un proceso dispone de acceso directo a un dispositivo, podría adoptar un comportamiento ''abusón'' de manera que no permitiera a otros procesos emplearlo.&lt;br /&gt;
&lt;br /&gt;
* '''Gestionar el acceso compartido''' a los dispositivos: Por ejemplo, un disco magnético puede ser accedido de forma compartida, mientras que un soporte de cinta, es deseable que no lo sea&lt;br /&gt;
&lt;br /&gt;
La forma de cubrir todas estas necesidades es crear la siguiente abstracción:&lt;br /&gt;
&lt;br /&gt;
[[Archivo:diseño modular.jpg|center|x400px]]&lt;br /&gt;
&lt;br /&gt;
'''Nota''': el SSI es una subrutina de manejo de interrupciones.&lt;/div&gt;</summary>
		<author><name>Rafesclir</name></author>	</entry>

	</feed>