Diferencia entre revisiones de «Diseño modular E/S»

De Wiki de Sistemas Operativos
Saltar a: navegación, buscar
(SSI)
m (Añadido hipervínculo: 10.4 Ejercicios de Entrada/Salida)
 
(No se muestran 13 ediciones intermedias de 9 usuarios)
Línea 1: Línea 1:
                                              \
+
El diseño de software de entrada/salida nos plantea las siguientes necesidades:
      Procesos de espacio de usuario          |
+
* 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.  
                                              |
 
      ----------------------------------      |
 
                                              |
 
        Llamadas al sistemas                |
 
        ej. open, read, write, close...      |
 
      (Software independiente de E/S)        >  Software
 
                                              |
 
      --------------------------------      |
 
                                              |
 
          Gestor de dispositivo  _____      |
 
                                |SSI        /
 
      --------------------------------     
 
                                              \
 
                Puerto de E/S                |
 
                                              |
 
          ---------------------------        >  Hardware   
 
                                              |
 
              Dispositivo E/S                |
 
                                              |
 
        ----------------------------          /
 
  
Los procesos de usuario no deben conocer los detalles del material, el SO se encarga de dar la API homogénea con la información de bajo nivel
+
* 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.
 +
 
 +
* Dar un '''criterio uniforme de denominación''': En sistemas Unix, por ejemplo, se trata a cada dispositivo como a un fichero
 +
 
 +
* '''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.
 +
 
 +
* 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.
 +
 
 +
* '''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
 +
 
 +
La forma de cubrir todas estas necesidades es crear la siguiente abstracción:
 +
 
 +
[[Archivo:diseño modular.jpg|center|x400px]]
 +
 
 +
'''Nota''': el SSI es una subrutina de manejo de interrupciones.
 +
 
 +
10.4 [[Ejercicios_de_Entrada/Salida | Ejercicios de Entrada/Salida]]

Revisión actual del 18:12 7 oct 2017

El diseño de software de entrada/salida nos plantea las siguientes necesidades:

  • 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.
  • 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.
  • Dar un criterio uniforme de denominación: En sistemas Unix, por ejemplo, se trata a cada dispositivo como a un fichero
  • 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.
  • 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.
  • 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

La forma de cubrir todas estas necesidades es crear la siguiente abstracción:

Diseño modular.jpg

Nota: el SSI es una subrutina de manejo de interrupciones.

10.4 Ejercicios de Entrada/Salida